This binutils patch was pushed by the original author using the word
"loosing", which means "to release" instead of "losing", meaning to drop
or misplace.
I did not change the spelling of the commit message inside the patch so
that the patch can still be tracked easily, but wanted to fix the
mistaken spelling which appears when the patch is applied when building
the crossgcc toolchain.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I66fd596a79c9eb331f473d175180cf7bb5a38529
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
rv32iafc-ilp32 is compatible with rv32iac-ilp32 for library
implementation, so add a reuse rule allowing the default configuration
to support rv32iafc.
-IAFC is an unusual configuration (much less common than -IMAFC),
but multilib reuse has essentially no cost: this change is useful to
users of platforms that support hardware floating-point but cannot
use hardware multiply/divide for any reason. To avoid generating a
new set of libraries this is limited to the soft-float ABI.
Tested by verifying that `gcc -march=rv32iafc -mabi=ilp32
--print-search-dirs` refers to the rv32iac/ilp32 library directory
as expected, rather than just the root library directory as occurs
when an unsupported target is selected (for instance, rv32id).
Change-Id: Ie056ba6488a138fe0876eebf7cbc59477b3c3518
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Newer host versions of gnatbind miss these when building the cross
gnat1 and gnatbind.
Tested with the following host compilers with and without bootstrapping
that the resulting coreboot images of three boards stay the same:
* GCC 4.9.2 (Debian)
* GCC 6.3 (Debian)
* GCC 7.4 (Debian)
* GCC 8.3 (Debian)
* GCC 9.4 (Debian)
* GCC 10.2 (Debian)
* GCC 12.1 (ArchLinux)
Change-Id: I09c6b3cc7b15f1c505acd3ec2c1959b101d6dfb7
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65000
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We used to disable individual warnings that are expected when building
our GCC version with a newer one. Not all warnings can be disabled
indvidually, though, and it's much easier to simply allow warnings.
As a plus, we get the warnings in the log (in case anybody would ever
look into it).
Partially fixes building with host GCC 12.1.
Change-Id: I8fafec4fc49db73b6dba311c775eea2cc92a9b48
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Various fixes to gnat and the improved nds32 backend have been merged
into gcc by now, so we don't need to carry those patches anymore.
Change-Id: Icdee2a8beedd109ee1f0eef6f32f7accbf66674b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
On some systems where the system compiler enables `-Wformat-security
-Werror=format-security` options by default, building libcpp fails
because the code passes a variable directly as a format string.
This change addresses this problem by patching the affected code.
Tested with the default compiler of Nixpkgs unstable, GCC 9.3.0 with the
options described above enabled by default.
Signed-off-by: Masanori Ogino <mogino@acm.org>
Change-Id: Ibf3c9e79ce10cd400c9f7ea40dd6de1ab81b50e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
While GMP supports fat builds on x86 that adapt to the CPU's
capabilities, by default it builds for the CPU of the builder.
Running that binary on an older CPU then can fail.
Change-Id: Iafdc2eb696189b9e2c5ead316f310d98c949ef74
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45044
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Unlike Linux kernel which has a static shadow region layout, we have
multiple stages in coreboot and thus require a different shadow offset
address. Unfortunately, GCC currently only supports adding a static
shadow offset at compile time using -fasan-shadow-offset flag.
For this reason, we enable GCC to determine asan shadow offset address
at runtime using a callback function named __asan_shadow_offset().
This supersedes the need to specify this address at compile time. GCC
then makes use of this shadow offset to protect stack buffers by
inserting red zones around them.
Some other benefits of having this GCC patch are:
a. We can place the shadow region in a separate linker section with
all its advantages like automatic fit insurance. This ensures if
a platform doesn't have enough memory space to hold shadow region,
the build will fail. (However, if we use a fixed shadow offset on a
platform that actually doesn't have enough memory, it may still
build without any errors.)
b. We don't modify the memory layout compared to the current one, as
we are placing the shadow region at the end of the space already
occupied by the program.
c. We can be much more flexible later if needed (thinking of other
stages like bootblock).
d. Since we are appending the shadow buffer to the region already
occupied, we make efficient use of the limited memory available
which is highly beneficial when using cache as ram.
Further, we have made sure that if you compile you tree with ASan
enabled but missed this patch, it will end up in the following
compilation error:
"invalid --param name 'asan-use-shadow-offset-callback'"
So, you cannot accidentally enable the feature without having your
compiler patched.
Change-Id: I401631938532a406a6d41e77c6c9716b6b2bf48d
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Update fixes build issues with host GCC 10.
Other changes:
https://acpica.org/node/177https://acpica.org/node/178https://acpica.org/node/179https://acpica.org/node/181
acpinames utility removed:
"Removed support for the acpinames utility. The acpinames was a simple
utility used to populate and display the ACPI namespace without executing
any AML code. However, ACPICA now supports executable opcodes outside of
control methods. This means that executable AML opcodes such as If and
Store opcodes need to be executed during table load. Therefore, acpinames
would need to be updated to match the same behavior as the acpiexec
utility and since acpiexec can already dump the entire namespace (via the
'namespace' command), we no longer have the need to maintain acpinames."
Change-Id: Ibd995561ca53458b04f87cee5693850c0d90d3d6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38907
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GCC 10 GNAT toolchain uses a new exception handler ABI, so older
GNAT cannot be built with GCC 10. This patch backports the new
exception handler in libgnat to make GNAT able to be built.
The libgnat patch doesn't remove the old exception handler, so it can
still be built with older compilers.
The cross toolchain can now be built with GCC 10.1.0 in Arch Linux
(with the latest IASL in CB:38907 that can be built in Arch), and the
toolchain can build a working coreboot image with libgfxinit for HP
EliteBook 2560p.
The original and patched crossgcc built with Debian 10.4 GCC 8.3.0,
and the patched crossgcc built with Arch GCC 10.1.0 generate identical
coreboot images with `make BUILD_TIMELESS=1`.
Change-Id: I757158056bf4698d3c68715e026c226615bc70a1
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42158
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
