Merge changes from topic "dynamic-toolchain" into integration

* changes:
build: allow multiple toolchain defaults
build: determine toolchain tools dynamically

build: allow multiple toolchain defaults

This change enables a fairly commonly-requested use-case, which is to
fall back to the host system's native toolchain when building on AArch64
if the bare-me

build: allow multiple toolchain defaults

This change enables a fairly commonly-requested use-case, which is to
fall back to the host system's native toolchain when building on AArch64
if the bare-metal toolchain is not available.

In this situation, if the `aarch64-none-elf` GCC toolchain cannot be
located, the build system will look for `aarch64-linux-gnu` before
giving up.

Change-Id: I39d2a8837b651b28cf0eafa92f6003a7f66767a0
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes from topic "makefile-cleanup" into integration

* changes:
build: improve diagnostics for unrecognized toolchain tools
build(rzg): separate BL2 and BL31 SREC generation
build(rcar

Merge changes from topic "makefile-cleanup" into integration

* changes:
build: improve diagnostics for unrecognized toolchain tools
build(rzg): separate BL2 and BL31 SREC generation
build(rcar): separate BL2 and BL31 SREC generation
build: separate preprocessing from DTB compilation
build: remove `MAKE_BUILD_STRINGS` function

show more ...

build: improve diagnostics for unrecognized toolchain tools

Up until recently the build system accepted an arbitrary value for `AS`
and, unbeknownst to anybody, was simply not making use of it. Rece

build: improve diagnostics for unrecognized toolchain tools

Up until recently the build system accepted an arbitrary value for `AS`
and, unbeknownst to anybody, was simply not making use of it. Recent
feedback has revealed that a number of contributors have `AS` explicitly
configured to use the GNU assembler, which is not a supported assembler,
and this breakage has yielded some cryptic error messages, e.g.:

aarch64-none-elf-as: unrecognized option '-x'

This change introduces human-readable diagnostics to help developers
with diagnosing unsupported toolchain tools:

The configured AArch64 assembler could not be identified and may not
be supported:

aarch64-none-elf-as

The default AArch64 assembler is:

aarch64-none-elf-gcc

The following tools are supported:

- Arm® Compiler for Embedded `armclang`
- LLVM Clang (`clang`)
- GNU GCC (`gcc`)

The build system will treat this assembler as GNU GCC (`gcc`).

Change-Id: I316036c83be2d45ee83a88846cf65c6ce7ae3c26
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "build: use GCC to link by default" into integration

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to support LTO, which can only be done when linking
is done via the C compiler, and we cannot change the linker later on if
some other part of the build system wants to enable LTO.

This change migrates the default choice of linker to GCC if the C
compiler is GCC, in order to enable this use-case. This should have no
impact on anything outside of the build system, as by default GCC merely
acts as a wrapper around BFD.

Change-Id: I40771be2b0571def67bbfde9e877e7629ec8cdaa
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "build: refactor toolchain detection" into integration

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default to

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default tools, identify the tools in use, and configure
toolchain flags.

To do this, we introduce three new concepts in this change:

- Toolchain identifiers,
- Tool class identifiers, and
- Tool identifiers.

Toolchain identifiers identify a configurable chain of tools targeting
one platform/machine/architecture. Today, these are:

- The host machine, which receives the `host` identifier,
- The AArch32 architecture, which receives the `aarch32` identifier, and
- The AArch64 architecture, which receivs the `aarch64` identifier.

The tools in a toolchain may come from different vendors, and are not
necessarily expected to come from one single toolchain distribution. In
most cases it is perfectly valid to mix tools from different toolchain
distributions, with some exceptions (notably, link-time optimization
generally requires the compiler and the linker to be aligned).

Tool class identifiers identify a class (or "role") of a tool. C
compilers, assemblers and linkers are all examples of tool classes.

Tool identifiers identify a specific tool recognized and supported by
the build system. Every tool that can make up a part of a toolchain must
receive a tool identifier.

These new identifiers can be used to retrieve information about the
toolchain in a more standardized fashion.

For example, logic in a Makefile that should only execute when the C
compiler is GNU GCC can now check the tool identifier for the C compiler
in the relevant toolchain:

ifeq ($($(ARCH)-cc-id),gnu-gcc)
...
endif

Change-Id: Icc23e43aaa32f4fd01d8187c5202f5012a634e7c
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...