=== Context ===
This patch is part of a patch series to add support for ARMv8-R
architecture. Its purpose is to rework the Tag_CPU_arch build attribute
value selection to (i) match architecture or CPU if specified by user
without any need for hack and (ii) match an architecture with all the
features used if in autodetection mode or return an error.
=== Motivation ===
Currently, Tag_CPU_arch build attribute value selection assumes that an
architecture is always a superset of architectures released earlier. As
such, the logic is to browse architectures in chronological order of
release and selecting the Tag_CPU_arch value of the last one to
contribute a feature used[1]/requested[2] not contributed by earlier
architectures.
[1] in case of autodetection mode
[2] otherwise, ie. in case of -mcpu/-march or associated directives
This logic fails the two objectives mentionned in the Context section.
First, due to the assumption it does an architecture can be selected
while not having all the features used/requested which fails the second
objective. Second, not doing an exact match when an architecture or CPU
is selected by the user means the wrong value is chosen when a later
architecture provides a subset of the feature bits of an earlier
architecture. This is the case for the implementation of ARMv8-R (see
later patch).
An added benefit of this patch is that it is possible to easily generate
more consistent build attribute by setting the feature bits from the
architecture matched in aeabi_set_public_attributes in autodetection
mode. This is better done as a separate patch because lots of testcase'
expected results must then be updated accordingly.
=== Patch description ===
The patch changes the main logic for Tag_CPU_arch and
Tag_CPU_arch_profile
values selection to:
- look for an exact match in case an architecture or CPU was specified
on the command line or in a directive
- select the first released architecture that provides a superset of the
feature used in the autodetection case
- select the most featureful architecture in case of -march=all
The array cpu_arch_ver is updated to include all architectures in order
to make the first point work.
Note that when looking for an exact match, the architecture with
selected extension is tried first and then only the architecture. This
is because some architectures are exactly equivalent to an earlier
architecture with its extensions selected. ARMv6S-M (= ARMv6-M + OS
extension) and ARMv6KZ (ARMv6K + security extension) are two such
examples.
Other adjustments are also necessary in aeabi_set_public_attributes to
make this change work.
1) The logic to set Tag_ARM_ISA_use and Tag_THUMB_ISA_use must check the
absence of feature bit used/requested to decide whether to give the
default value for empty files (see EABI attribute defaults test). It was
previously checking that arch == 0 which would only happen if no feature
bit could be matched by any architecture, ie there is no feature bit to
match.
2) A fallback to a superset match must exist when no_cpu_selected ()
returns true. This is because aeabi_set_public_attributes is called
again after relaxation and at this point selected_cpu is set from the
previous execution of that function. There is therefore no way to check
whether the user specified an architecture or CPU.
3) Tag_CPU_arch lines are removed from expected output when the
detected architecture should be pre-ARMv4, since 0 is the Tag_CPU_arch
value for pre-ARMv4 architectures and default value for an absent entry
is 0.
2017-06-21 Thomas Preud'homme <thomas.preudhomme@arm.com>
gas/
* config/tc-arm.c (fpu_any): Defined from FPU_ANY.
(cpu_arch_ver): Add all architectures and sort by release date.
(have_ext_for_needed_feat_p): New.
(get_aeabi_cpu_arch_from_fset): New.
(aeabi_set_public_attributes): Call above function to determine
Tag_CPU_arch and Tag_CPU_arch_profile values. Adapt Tag_ARM_ISA_use
and Tag_THUMB_ISA_use selection logic to check absence of feature bit
accordingly.
* testsuite/gas/arm/attr-march-armv1.d: Fix expected Tag_CPU_arch build
attribute value.
* testsuite/gas/arm/attr-march-armv2.d: Likewise.
* testsuite/gas/arm/attr-march-armv2a.d: Likewise.
* testsuite/gas/arm/attr-march-armv2s.d: Likewise.
* testsuite/gas/arm/attr-march-armv3.d: Likewise.
* testsuite/gas/arm/attr-march-armv3m.d: Likewise.
* testsuite/gas/arm/pr12198-2.d: Likewise.
include/
* opcode/arm.h (FPU_ANY): New macro.
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
README for GAS
A number of things have changed since version 1 and the wonderful
world of gas looks very different. There's still a lot of irrelevant
garbage lying around that will be cleaned up in time. Documentation
is scarce, as are logs of the changes made since the last gas release.
My apologies, and I'll try to get something useful.
Unpacking and Installation - Summary
====================================
See ../binutils/README.
To build just the assembler, make the target all-gas.
Documentation
=============
The GAS release includes texinfo source for its manual, which can be processed
into `info' or `dvi' forms.
The DVI form is suitable for printing or displaying; the commands for doing
this vary from system to system. On many systems, `lpr -d' will print a DVI
file. On others, you may need to run a program such as `dvips' to convert the
DVI file into a form your system can print.
If you wish to build the DVI file, you will need to have TeX installed on your
system. You can rebuild it by typing:
cd gas/doc
make as.dvi
The Info form is viewable with the GNU Emacs `info' subsystem, or the
stand-alone `info' program, available as part of the GNU Texinfo distribution.
To build the info files, you will need the `makeinfo' program. Type:
cd gas/doc
make info
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 in a
`--target=TARGET' option. The equivalent full name is
`sparc-sun-sunos4'.
The `configure' script accompanying GAS 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 i386v
i386-unknown-sysv
% sh config.sub i786v
Invalid configuration `i786v': machine `i786v' not recognized
`configure' options
===================
Here is a summary of the `configure' options and arguments that are
most often useful for building GAS. `configure' also has several other
options not listed here.
configure [--help]
[--prefix=DIR]
[--srcdir=PATH]
[--host=HOST]
[--target=TARGET]
[--with-OPTION]
[--enable-OPTION]
You may introduce options with a single `-' rather than `--' if you
prefer; but you may abbreviate option names if you use `--'.
`--help'
Print a summary of the options to `configure', and exit.
`-prefix=DIR'
Configure the source to install programs and files under directory
`DIR'.
`--srcdir=PATH'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`--host=HOST'
Configure GAS to run on the specified HOST. Normally the
configure script can figure this out automatically.
There is no convenient way to generate a list of all available
hosts.
`--target=TARGET'
Configure GAS for cross-assembling programs for the specified
TARGET. Without this option, GAS is configured to assemble .o files
that run on the same machine (HOST) as GAS itself.
There is no convenient way to generate a list of all available
targets.
`--enable-OPTION'
These flags tell the program or library being configured to
configure itself differently from the default for the specified
host/target combination. See below for a list of `--enable'
options recognized in the gas distribution.
`configure' accepts other options, for compatibility with configuring
other GNU tools recursively; but these are the only options that affect
GAS or its supporting libraries.
The `--enable' options recognized by software in the gas distribution are:
`--enable-targets=...'
This causes one or more specified configurations to be added to those for
which BFD support is compiled. Currently gas cannot use any format other
than its compiled-in default, so this option is not very useful.
`--enable-bfd-assembler'
This causes the assembler to use the new code being merged into it to use
BFD data structures internally, and use BFD for writing object files.
For most targets, this isn't supported yet. For most targets where it has
been done, it's already the default. So generally you won't need to use
this option.
Compiler Support Hacks
======================
On a few targets, the assembler has been modified to support a feature
that is potentially useful when assembling compiler output, but which
may confuse assembly language programmers. If assembler encounters a
.word pseudo-op of the form symbol1-symbol2 (the difference of two
symbols), and the difference of those two symbols will not fit in 16
bits, the assembler will create a branch around a long jump to
symbol1, and insert this into the output directly before the next
label: The .word will (instead of containing garbage, or giving an
error message) contain (the address of the long jump)-symbol2. This
allows the assembler to assemble jump tables that jump to locations
very far away into code that works properly. If the next label is
more than 32K away from the .word, you lose (silently); RMS claims
this will never happen. If the -K option is given, you will get a
warning message when this happens.
REPORTING BUGS IN GAS
=====================
Bugs in gas should be reported to:
bug-binutils@gnu.org.
They may be cross-posted to gcc-bugs@gnu.org if they affect the use of
gas with gcc. They should not be reported just to gcc-bugs, since not
all of the maintainers read that list.
See ../binutils/README for what we need in a bug report.
Copyright (C) 2012-2017 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.
2c6b98ea6f