Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated li

Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated libraries

show more ...

build: use parameters in calls to `MAKE_DEP`

This is a small change to the behaviour of the `MAKE_DEP` macro to force
it to take its inputs as arguments, rather than assuming the variables
that its

build: use parameters in calls to `MAKE_DEP`

This is a small change to the behaviour of the `MAKE_DEP` macro to force
it to take its inputs as arguments, rather than assuming the variables
that its inputs come from.

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

show more ...

build: use full paths for generated libraries

This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that a

build: use full paths for generated libraries

This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that are generated, rather than their phony target aliases
and `-lX` link flags.

The goal of this is to clean up Make's view of the dependencies between
files, avoiding phony targets (which do not honour timestamps) making
their way into intermediate dependencies.

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

show more ...

Merge changes If56ed0ab,I632236a1 into integration

* changes:
perf(build): don't check the compiler's flags for every target
perf(build): be clever about uppercasing

perf(build): don't check the compiler's flags for every target

The TF_FLAGS variable must be recursively expanded as the rules that use
it are defined before it has been fully defined. That has the

perf(build): don't check the compiler's flags for every target

The TF_FLAGS variable must be recursively expanded as the rules that use
it are defined before it has been fully defined. That has the
unfortunate side effect of spawning a subshell that calls the compiler
for every file that is being built, thrashing multicore build times.

We don't cater to the possibility of the toolchain changing mid build so
precomputing this value would be more sensible. Doing a clean build on
an Intel dual socket Xeon Gold 5218 (i.e. 64 threads) workstation used
to take about 9 seconds. After this patch it takes about 1.5. Single
core performance went from ~45 seconds to about 25.

Change-Id: If56ed0ab3cc42bc482d9dd05a41ffbff4dd7f147
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

perf(build): be clever about uppercasing

Most of the macros in build_macros.mk get lazily evaluated. That's
mostly fine, except for the fact that the `uppercase` macro needs to
spawn a subshell to g

perf(build): be clever about uppercasing

Most of the macros in build_macros.mk get lazily evaluated. That's
mostly fine, except for the fact that the `uppercase` macro needs to
spawn a subshell to get its output. And the target for every file
requires calling `uppercase` many, MANY, times, thrashing performance on
even the most trivial of make commands.

We can be a little clever and only call `uppercase` a handful of times
and then pass around the already uppercased strings.

The same is true about the verbosity augmentation variables. Simply
changing them to simply expanded variables allows for them to be
pre-processed and then used over and over again.

`make realclean` is a pretty good benchmark for this as it doesn't do
much else but must process all the rules, like every other make command.
On a clean checkout of TF-A on an Intel Xeon Gold 5218 (i.e. slow
single-core) workstation, that command used to take about 7 seconds.
With this patch it takes about 0.5.

Change-Id: I632236a12a40f169e834974ecbc73ff80aac3462
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge changes from topic "romlib-fixes" into integration

* changes:
fix(romlib): wrap indirectly included functions
fix(arm): remove duplicate jumptable entry

fix(romlib): wrap indirectly included functions

The problem that this resolves is a bit involved; the following
must be met at the same time for some function <to_be_wrapped>:

* to_be_wrapped must

fix(romlib): wrap indirectly included functions

The problem that this resolves is a bit involved; the following
must be met at the same time for some function <to_be_wrapped>:

* to_be_wrapped must be specified as part of the romlib
* to_be_wrapped must _not_ be referenced by any translation unit
in TF-A
* to_be_wrapped must be referenced by a translation unit in a
dependent library, mbedtls for example.

Under these circumstances, to_be_wrapped will not be wrapped, and
will instead reference its original definition while simultaneously
residing in romlib.

This is a side effect of two issues with romlib prior to this patch:

1 to_be_wrapped is expected to wrap by duplicating its definition.
This causes any condition that links against both the base and
wrapper functions to be a link error (duplicate symbol definition).
2 to_be_wrapped is in its own translation unit
This causes the wrappers to be used by TF-A in an as needed.

The duplicate function definitions can be worked around using the
linker's `--wrap` flag, which redirects all references to a symbol
to resolve to `__wrap_<symbol>` and the original symbol to be
available as `__real_<symbol>`. Most of the changes handle creating
this arguments and passing them to the linker.

Further, once you use the linker's wrap, you will encounter another
issue: if TF-A does not use a function, its wrapper is not present.
This causes link issues when a library and not TF-A uses the wrapper.
Note that this issue would have been resolved previously by ignoring
the wrapper and using the base definition.

This further issue is worked around by concatenating the assembly for
all of the wrappers into a single translation unit. It's possible to
work around this issue in a few other ways, including reordering the
libraries passed to the linker to place libwrapper.a last or grouping
the libraries so that symbols from later libraries may be resolved
with prior libraries.

I chose the translation unit concatenation approach as it revealed
that a jumptable has duplicate symbols within it.

Change-Id: Ie57b5ae69bde2fc8705bdc7a93fae3ddb5341ed9
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>

show more ...

Merge "build: consolidate directory creation rules" into integration

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We cur

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We currently use several macros to generate rules to create directories
upon dependence, which is a significant amount of code and a lot of
redundancy. The rule introduced by this change represents a catch-all:
any rule dependency on a path ending in a forward slash is automatically
created.

Now, rules can rely on an unordered dependency (`|`) on `$$(@D)/` which,
when secondary expansion is enabled, expands to the directory of the
target being built, e.g.:

build/main.o: main.c | $$(@D)/ # automatically creates `build/`

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

show more ...

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing facilities to utilities

show more ...

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables are boolean values determining
whether the build system has been configured to run silently or
verbosely respectively (i.e. with `--silent` or `V=1`).

These two modes cannot be used together - if `silent` is truthy then
`verbose` is always falsy. As such:

make --silent V=1

... results in a silent build.

In addition to these boolean variables, we also introduce two new
variables - `s` and `q` - for use in rule recipes to conditionally
suppress the output of commands.

When building silently, `s` expands to a value which disables the
command that follows, and `q` expands to a value which supppresses
echoing of the command:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed but not echoed'

When building verbosely, `s` expands to a value which disables the
command that follows, and `q` expands to nothing:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed and echoed'

In all other cases, both `s` and `q` expand to a value which suppresses
echoing of the command that follows:

$(s)echo 'This command is executed but not echoed'
$(q)echo 'This command is executed but not echoed'

The `s` variable is predominantly useful for `echo` commands, where you
always want to suppress echoing of the command itself, whilst `q` is
more useful for all other commands.

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

show more ...

build: add string casing facilities to utilities

This is a small modification to two existing functions in the build
system: `uppercase` and `lowercase`.

These functions have been moved to the comm

build: add string casing facilities to utilities

This is a small modification to two existing functions in the build
system: `uppercase` and `lowercase`.

These functions have been moved to the common utilities makefile, and
use the `tr` tool to simplify their implementation. Behaviour is, for
virtually all use-cases, identical.

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

show more ...

Merge changes from topics "ck/tf-a-build-fixes", "ck/tf-a-romlib-build-fixes" into integration

* changes:
build(romlib): don't timestamp generated wrappers
build(romlib): de-duplicate ROMLib wra

Merge changes from topics "ck/tf-a-build-fixes", "ck/tf-a-romlib-build-fixes" into integration

* changes:
build(romlib): don't timestamp generated wrappers
build(romlib): de-duplicate ROMLib wrapper sources
fix(build): fix incorrectly-escaped armlink preprocessor definitions

show more ...

fix(build): fix incorrectly-escaped armlink preprocessor definitions

Preprocessor definitions that are passed to armlink are currently not
correctly escaped, resulting in the shell trying to parse t

fix(build): fix incorrectly-escaped armlink preprocessor definitions

Preprocessor definitions that are passed to armlink are currently not
correctly escaped, resulting in the shell trying to parse the
parentheses contained in some of the preprocessor definitions:

```
LD build/tegra/t210/release/bl31/bl31.elf
/bin/sh: 1: Syntax error: "(" unexpected
```

This change ensures that these preprocessor definitions are adequately
escaped for the shell.

Change-Id: I9d2c60fa60c0aa00770417a68f900e9fb84b4669
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: separate preprocessing from DTB compilation

This is a small change to separate preprocessing of device tree sources
into their own build step as opposed to combining them. The impact of
this

build: separate preprocessing from DTB compilation

This is a small change to separate preprocessing of device tree sources
into their own build step as opposed to combining them. The impact of
this is more on separation of concerns than anything tangible, but it's
helpful to avoid doing more than necessary in a build rule.

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

show more ...

build: remove `MAKE_BUILD_STRINGS` function

This function causes the build message to be generated and compiled in
two different ways, with one way done inside `build_macros.mk` and the
other done i

build: remove `MAKE_BUILD_STRINGS` function

This function causes the build message to be generated and compiled in
two different ways, with one way done inside `build_macros.mk` and the
other done inside `windows.mk`, mostly because it's done by generating
the C file on the command line.

We can instead replace this whole build message generation sequence with
a simple standard C compilation command and a normal C file.

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

show more ...

Merge "fix(build): wrap toolchain paths in double quotes" into integration

fix(build): wrap toolchain paths in double quotes

Fix issue with Windows paths containing spaces. Recent toolchain
refactoring (cc277de) caused a regression in the Windows build. Ensure
toolchain pa

fix(build): wrap toolchain paths in double quotes

Fix issue with Windows paths containing spaces. Recent toolchain
refactoring (cc277de) caused a regression in the Windows build. Ensure
toolchain path utilities wrap paths in double quoted strings.

Change-Id: I7a136e459d85cff1e9851aedf0a5272a841df09c
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Signed-off-by: Chris Kay <chris.kay@arm.com>
Co-authored-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "build: use toolchain identifiers in conditions" into integration

Merge "build: use new toolchain variables for tools" into integration

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the build system. This change replaces the various conditions that
are in use to identify these tools based on the path with a standard set
of comparisons against these new identifier variables.

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

show more ...

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

Merge changes from topic "gr/build_refac" into integration

* changes:
refactor(build): minor updates
refactor(build): remove enabling feat
fix(build): march handling with arch-features
refac

Merge changes from topic "gr/build_refac" into integration

* changes:
refactor(build): minor updates
refactor(build): remove enabling feat
fix(build): march handling with arch-features
refactor(build): refactor mandatory options

show more ...