Merge "fix(build): set linker to lld before evaluating ld_option" into integration

fix(build): set linker to lld before evaluating ld_option

This ensures ld_option is called with valid -fuse-ld option, therefore
filtering options against ones supported by lld and not the
system de

fix(build): set linker to lld before evaluating ld_option

This ensures ld_option is called with valid -fuse-ld option, therefore
filtering options against ones supported by lld and not the
system default linker Clang chooses without the option specified.

This change should not affect toolchains other than llvm-clang, since it
only moves a conditional concerning the said toolchain.

Resolves the following linking error that manifests itself when using
Clang versions 21 and higher for building TF-A:

> ld.lld: error: unknown argument '--no-warn-rwx-segments'

Change-Id: I466f733377327a7c38ee27899be6681debf61e11
Signed-off-by: Dmitrii Sharshakov <d3dx12.xx@gmail.com>

show more ...

Merge changes Ia8b52237,Id4b7714e into integration

* changes:
fix(build): put the -target definitions in toolchain.mk
fix(build): align the cpu-ops flags with all others

fix(build): put the -target definitions in toolchain.mk

Knowing the target is quite important and must be known early - it is
necessary for flag discovery and should be available much earlier than
c

fix(build): put the -target definitions in toolchain.mk

Knowing the target is quite important and must be known early - it is
necessary for flag discovery and should be available much earlier than
cflags.mk's inclusion. So put it in toolchain.mk with the rest of the
toolchain configuration.

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

show more ...

fix(build): align the cpu-ops flags with all others

Since the cpu-ops file was created we've obtained the constraints.mk and
cflags.mk files and we also have the defaults.mk. The cpu-ops file is
not

fix(build): align the cpu-ops flags with all others

Since the cpu-ops file was created we've obtained the constraints.mk and
cflags.mk files and we also have the defaults.mk. The cpu-ops file is
not much different to these three, just much more complex. This patch
keeps the complicated bit in cpu-ops.mk but it makes it behave like
defaults.mk. The non-complicated bits (like cross referencing and
compiler flags) go to their corresponding files. This centralises
responsibilities and makes it nicer to keep track of.

The reason for doing this untangling is that the order of defaulting,
cross referencing, and compiler flag selection is significant and we can
run into problems where seemingly identical lines of code produce
different outcomes.

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

show more ...

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
fe

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
feat(build): allow full LTO builds with clang
refactor(build): make sorting of sections generic
feat(build): use clang as a linker
fix(build): correctly detect that an option is missing with ld_option
feat(build): pass cflags to the linker when LTO is enabled

show more ...

refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS

WRAPPER_FLAGS is this awkward exception to linker related flags that is
defined in the build_macros file which is only meant to provide macros.
It

refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS

WRAPPER_FLAGS is this awkward exception to linker related flags that is
defined in the build_macros file which is only meant to provide macros.
It also relies on being lazily evaluated as at the time of its expansion
BUILD_PLAT is not defined yet. It's also another variable in the myriad
of others.

So absorb it into ldflags-common in cflags.mk. This brings it in line
with all the rest and gets rid of its weird quirkiness.

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

show more ...

fix(build): simplify the -target options

It turns out that there are a lot of ways to specify the target
triplets, some of which are identical in meaning. This allows us to use
a single unambiguous

fix(build): simplify the -target options

It turns out that there are a lot of ways to specify the target
triplets, some of which are identical in meaning. This allows us to use
a single unambiguous triplet regardless of build flags.

This was spotted in
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36980/comment/ced50479_a1e937c0/

Change-Id: I531a2ee17e621c93373f9ededc0e654c79480e31
Co-developed-by: Chris Kay <chris.kay@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

feat(build): allow full LTO builds with clang

GCC doesn't like LTOing __builtins. This has been broken for time
immemorial (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215) and
there is no fi

feat(build): allow full LTO builds with clang

GCC doesn't like LTOing __builtins. This has been broken for time
immemorial (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215) and
there is no fix coming. Prior to GCC 14 a build of the libc with LTO
will simply not work. From GCC14 a workaround is possible passing
-ffat-lto-objects. The underlying issue is that the linker "forgets"
about builtin symbols it added during LTO. The non-LTO copies make these
forgotten functions available during final resolution. However, this
still does not LTO the libc, it just allows for it to build with -flto.

Since GCC is our main compiler, and we do not differentiate the libc
from any other lib we build, we have simply not built libs with LTO so
far. However, there is no need to kneecap clang for GCC's failings, so
LTO all libs on clang when enabled.

When GCC14 becomes the oldest reasonable compiler we support, this can
be done for GCC too, although with the workaround above. This still
won't LTO the libc, but it will at least LTO other libs.

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

show more ...

refactor(build): make sorting of sections generic

All BLs define essentially the same sequence for sorting of sections.
Make that generic so it applies more easily.

Change-Id: I81f5f6635232bd43d999

refactor(build): make sorting of sections generic

All BLs define essentially the same sequence for sorting of sections.
Make that generic so it applies more easily.

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

show more ...

feat(build): use clang as a linker

To support LTO, the gcc binary is used as a compiler, assembler, and
linker. Do the same for clang and enable LTO builds with it as a side
effect.

This simplifies

feat(build): use clang as a linker

To support LTO, the gcc binary is used as a compiler, assembler, and
linker. Do the same for clang and enable LTO builds with it as a side
effect.

This simplifies code quite a bit as the gcc/clang different is much
smaller. Support for ld/lld (if overriden with LD) is maintained.

This is a good time to convert tabs to spaces to conform to make's
expectations on syntax.

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

show more ...

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for bo

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for both styles
of invocation. However, the gcc one is incorrect - gcc returns `0` even
when it has printed an error saying that it doesn't recognise the
option. Add a discovery function for each linker we expect and
dynamically dispatch to the correct one.

While we're at it, also add a little bit of code to return the -Wl
prefix for gcc and not for ld.

All of the above is also true for clang and lld, although they don't
suffer from the problem that gcc does.

Change-Id: I4f7bdf40c01f4c5df9c177f5048f5e349bc2b9c9
Co-authored-by: Chris Kay <chris.kay@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pa

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pass the same flags to the compilation and linking stages when we enable
LTO. This is crucial for things like the undefined behaviour sanitiser.
Anecdotally, in working on this, there have been a fair few errors that
the compiler has only been able to catch due to warning flags being
passed to the linker and building with LTO.

This patch puts the contents of TF_CFLAGS into TF_LDFLAGS when LTO is
enabled. This is easier said than done, however, as we support building
with clang and linking with gcc (or vice versa), so CFLAGS that are
discovered for one will not work for the other. This patch works around
this by splitting all flags into a per-compiler variable. Then CFLAGS
and LDFLAGS get the contents of the correct one.

Some notable side effects: CPPFLAGS and TF_CFLAGS_$(ARCH) become empty
and are removed, although expanding them is kept as platforms set them.
Some flags become duplicate and are removed form TF_LDFLAGS (eg -O1).

The errata (--fix) flags are kept as-is but moved to cpu-ops.mk for
consistency. This is because they currently don't work with LTO and will
be addressed in a later patch.

Finally, ERROR_DEPRECATED's flags are also identical on all compilers so
don't maintain a difference.

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

show more ...

Merge changes I801cea04,I4abb6c9d,I3c1cc0ec,I1b6f69ad,Ic4086a1f into integration

* changes:
refactor(build): pass TF_CFLAGS to the assembler
refactor(build): absorb CFLAGS into TF_CFLAGS
refac

Merge changes I801cea04,I4abb6c9d,I3c1cc0ec,I1b6f69ad,Ic4086a1f into integration

* changes:
refactor(build): pass TF_CFLAGS to the assembler
refactor(build): absorb CFLAGS into TF_CFLAGS
refactor(build): use a standard rule to run the preprocessor
refactor(build): place all cflags setting in one place
refactor(build): simplify ENABLE_LTO checking

show more ...

refactor(build): pass TF_CFLAGS to the assembler

The assembler is already invoked through the gcc/llvm wrapper so will
understand the TF_CFLAGS out of the box. TF_CFLAGS are also quite
comprehensive

refactor(build): pass TF_CFLAGS to the assembler

The assembler is already invoked through the gcc/llvm wrapper so will
understand the TF_CFLAGS out of the box. TF_CFLAGS are also quite
comprehensive. So don't duplicate the definitions and use it directly.
This also allows to absorb TF_CFLAGS_$(ARCH) and CPPFLAGS and reduce
the number of permutations of flags we pass.

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

show more ...

refactor(build): absorb CFLAGS into TF_CFLAGS

CFLAGS is the standard and expected variable for passing flags to the
compiler. The build system also uses TF_CFLAGS to define its own flags.
But the bu

refactor(build): absorb CFLAGS into TF_CFLAGS

CFLAGS is the standard and expected variable for passing flags to the
compiler. The build system also uses TF_CFLAGS to define its own flags.
But the build rules need to specify both. So append CFLAGS to TF_CFLAGS
so that only the latter needs to be passed.

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

show more ...

refactor(build): use a standard rule to run the preprocessor

There are a few, functionally identical, ways to call the preprocessor
on a non-C file, depending on the file. They differ in subtle, not

refactor(build): use a standard rule to run the preprocessor

There are a few, functionally identical, ways to call the preprocessor
on a non-C file, depending on the file. They differ in subtle, not
entirely correct, ways - one is missing a dependency to the makefiles,
another generates its .d inline, and the prints are different. That has
resulted in platforms reimplementing this functionality, making the
build brittle - a change to the overall build system doesn't propagate.
So add a MAKE_PRE macro that will make a rule with all the bells and
whistles to run the preprocessor on an arbitrary file.

This patch converts the arm platforms' cot_descriptors DTS rules. The
files are renamed to fit with the build rule and all extra flags are
dropped. Those flags are only necessary for building BL2 c files, which
will be passed to the output C file. Only the DTS flags are needed for
the preprocessing step, which will be passed automatically.

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

show more ...

refactor(build): place all cflags setting in one place

The top-level Makefile has to come up with a list of flags to pass to
the compiler. It has to do so while considering a variety of options and

refactor(build): place all cflags setting in one place

The top-level Makefile has to come up with a list of flags to pass to
the compiler. It has to do so while considering a variety of options and
constraints. This has generally done in the most convenient place in the
file. However, it causes problems with evaluation - options may be set
after they are used, there may be platform dependencies, DEFINES, etc.
As a result flags must be lazily evaluated and they lack any cohesive
design.

To enable a solution to this, extract all CFLAGS/LDFLAGS/ASFLAGS
configuration to a new file. Reorder rules slightly to put related rules
closer together and call the entire thing as late as possible - after
platform.mk and after the DEFINES are known.

There is a small number of libraries that set flags in their own sub
makefiles. As these contain the entire feature, do not move their flags
to keep them self-contained. This is okay as these makefile will be
evaluated before the cflags.

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

show more ...