Merge "build: skip toolchain detection for some targets" into integration

build: skip toolchain detection for some targets

Most developers run the `clean`, `checkpatch` and other similar targets
without specifying any other additional build options. When combined
with a f

build: skip toolchain detection for some targets

Most developers run the `clean`, `checkpatch` and other similar targets
without specifying any other additional build options. When combined
with a flow where the developer passes `CROSS_COMPILE` or `CC`
explicitly, and where the default-configured tools are not on the PATH,
these targets will warn about unrecognized toolchain tools.

This change is a workaround for this whereby the toolchain makefile is
not expanded unless a target *not* named `*clean`, `check*` `doc` or
`*tool` has been specified.

Change-Id: I2f2a275964b65253df07c2207043217b14f615fe
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: use new toolchain variables for tools" into integration

Merge "build: refactor toolchain detection" into integration

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by the toolchain refactor patch. These variables should be
equivalent to the values that they're replacing.

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

show more ...

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 ...

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments`

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments` when linking with GCC
build: always use the C compiler to assemble
build: always use the C compiler to preprocess
fix(rcar): fix implicit rule invocations in tools

show more ...

build: prefer `gcc-ar` over `ar`

The `gcc-ar` wrapper exists to make it easier to support LTO on some
versions of GCC. The two commands are compatible, accepting exactly the
same arguments, so this

build: prefer `gcc-ar` over `ar`

The `gcc-ar` wrapper exists to make it easier to support LTO on some
versions of GCC. The two commands are compatible, accepting exactly the
same arguments, so this change moves us to `gcc-ar` to ensure that we
are configuring LTO correctly.

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

show more ...

build: always use the C compiler to assemble

The ROM library is the only component in the repository that compiles
assembly files using the assembler directly. This change migrates it to
the C compi

build: always use the C compiler to assemble

The ROM library is the only component in the repository that compiles
assembly files using the assembler directly. This change migrates it to
the C compiler instead, like the rest of the project.

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

show more ...

build: always use the C compiler to preprocess

We're a bit inconsistent about which tool we use to preprocess source
files; in some places we use `$(CC) -E` whilst in others we use `cpp`.

This chan

build: always use the C compiler to preprocess

We're a bit inconsistent about which tool we use to preprocess source
files; in some places we use `$(CC) -E` whilst in others we use `cpp`.

This change forces all invocations of the C preprocessor to use the
first scheme, which ensures that the preprocessor behaves the same way
as the C compiler used when compiling C source files.

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

show more ...

Merge "chore: update to use Arm word across TF-A" into integration

chore: update to use Arm word across TF-A

Align entire TF-A to use Arm in copyright header.

Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.co

chore: update to use Arm word across TF-A

Align entire TF-A to use Arm in copyright header.

Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge "Use abspath to dereference $BUILD_BASE" into integration

Use abspath to dereference $BUILD_BASE

If the user tries to change BUILD_BASE to put the build products outside
the build tree the compile will fail due to hard coded assumptions that
$BUILD_BASE is

Use abspath to dereference $BUILD_BASE

If the user tries to change BUILD_BASE to put the build products outside
the build tree the compile will fail due to hard coded assumptions that
$BUILD_BASE is a relative path. Fix by using $(abspath $(BUILD_BASE))
to rationalize to an absolute path every time and remove the relative
path assumptions.

This patch also adds documentation that BUILD_BASE can be specified by
the user.

Signed-off-by: Grant Likely <grant.likely@arm.com>
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ib1af874de658484aaffc672f30029b852d2489c8

show more ...

Merge "Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__" into integration

Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__

NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.

All common C compilers predefine a macro called __ASSEMBLER__ when
pre

Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__

NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.

All common C compilers predefine a macro called __ASSEMBLER__ when
preprocessing a .S file. There is no reason for TF-A to define it's own
__ASSEMBLY__ macro for this purpose instead. To unify code with the
export headers (which use __ASSEMBLER__ to avoid one extra dependency),
let's deprecate __ASSEMBLY__ and switch the code base over to the
predefined standard.

Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417
Signed-off-by: Julius Werner <jwerner@chromium.org>

show more ...

Merge "Romlib makefile refactoring and script rewriting" into integration

Romlib makefile refactoring and script rewriting

The features of the previously existing gentbl, genvar and genwrappers
scripts were reimplemented in the romlib_generator.py Python script.
This resu

Romlib makefile refactoring and script rewriting

The features of the previously existing gentbl, genvar and genwrappers
scripts were reimplemented in the romlib_generator.py Python script.
This resulted in more readable and maintainable code and the script
introduces additional features that help dependency handling in
makefiles. The assembly templates were separated from the script logic
and were collected in the 'templates' directory.

The targets and their dependencies were reorganized in the makefile and
the dependency handling of included index files is possible now.
Incremental build is available in case of modifying the index files.

Signed-off-by: Imre Kis <imre.kis@arm.com>
Change-Id: I79f65fab9dc5c70d1f6fc8f57b2a3009bf842dc5

show more ...

Merge "Introduce BTI support in ROMLIB" into integration

Introduce BTI support in ROMLIB

When TF-A is compiled with BTI enabled, the branches in the ROMLIB
jumptable must be preceded by a "bti j" instruction.

Moreover, when the additional "bti" instructi

Introduce BTI support in ROMLIB

When TF-A is compiled with BTI enabled, the branches in the ROMLIB
jumptable must be preceded by a "bti j" instruction.

Moreover, when the additional "bti" instruction is inserted, the
jumptable entries have a distance of 8 bytes between them instead of 4.
Hence, the wrappers are also modified accordinly.

If TF-A is compiled without BTI enabled, the ROMLIB jumptable and
wrappers are generated as before.

Change-Id: Iaa59897668f8e59888d39046233300c2241d8de7
Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>

show more ...

Merge "romlib: Improve compilation flags definition" into integration

romlib: Improve compilation flags definition

* Optimization flags were only provided for debug build.
* Set optimisation level to -O1
* Remove CFLAGS which is never used for romlib
* Remove the igno

romlib: Improve compilation flags definition

* Optimization flags were only provided for debug build.
* Set optimisation level to -O1
* Remove CFLAGS which is never used for romlib
* Remove the ignored -g flag from LDFLAGS

Change-Id: Id4b69026d8a322ed4cb0acf06c350f13d31571ad
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

show more ...

Merge pull request #1902 from jts-arm/romlib

ROMLIB bug fixes