By default GCC for ARC is configured with ARC700 CPU.
This means when we don't pass "-mcpu=xxx":
a) Code will be compiled for ARC700
b) Libs will used for ARC700
And if we happen to run on ARCv2 core like ARC HSxx we
won't be able to use target gcc w/o "-mcpu=xxx" which
is not very convenient as we want to build "target" toolchain
but not canadian-cross.
Note the trick here is we set TUNE_PKGARCH in just 2 values,
it is either "arc700" for all ARCompact cores (ARC750 & ARC770)
and "archs" for all ARCv2 cores (ARC HS38 & HS48), see [1].
This gives us usable defaults.
For cross-compilation we use TUNE_CCARGS for fine-tuning depending
on which HW features we have on the current target so that
we may have HW feature A & B or B & C or A & B & C, see [2].
[1] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L4
[2] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L34
(From OE-Core rev: 6d2e44db7ebada41ad1cfc1c98ce9012242ced11)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this the build fails for armv6t targets due to invalid
assembler instructions in thumb mode.
[YOCTO #12929]
(From OE-Core rev: 801141be68e5c754f2cd1d80d13982f037fc03e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Passing --with-mpfr and --with-mpc when compiling the cross compiler
appears to be at best unnecessary, and at worst can cause build failures.
Firstly, the paths passed in gcc-cross-canadian are using the undefined
${layout_exec_prefix}. This results in configure passing
-I${STAGING_DIR_HOST}/include twice to the compiler when it's doing its
test builds. This is mostly pointless since that directory doesn't exist
with the default oe-core configuration - the correct path would be
-I${STAGING_DIR_HOST}/usr/include.
The path for mpfr passed in gcc-cross is correct, but unnecessary since it
is just the sysroot default.
I've gone back through the history, and it seems that these lines (or
similar ones) were originally added way back in
8800d8be25 for GCC 4.1.1 in 2006! I asked[1]
if anyone knew why this was necessary but received no response, so I can
only assume that no-one knows.
I've successfully built for various targets with this patch applied and
observed no problems.
[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-September/155971.html
(From OE-Core rev: 2f9f02d5fda9884ccf9ae22ceb00d59b99036a49)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCC's built-in spec for LD is missing a space after
"--eh-frame-hdr" thus with the next option merged together they
are not understood by LD and so LD fails.
Back-port from upstream GCC, see:
892142379c
(From OE-Core rev: 0757187bdbed3025b022a82dd85ee35dc7b71f1f)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These patches may as well be merged together as they affect the same code
and things are clearer this way.
(From OE-Core rev: 7533c000183a2b447cbabd6ce1b8b75de55b63e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
C++ applications that contain a specfic use of std::pair with tempates
cause the build to require many gigabytes of RAM to build.
This is a fix that was applied to the upstream GCC 7 branch.
Change-Id: I213f96d1d6332e2dce5765482ff3413f1abd7ff8
(From OE-Core rev: 51a09ba2729a840a9f2f87b68c7f50a3e6ac0d04)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building on ppc64le hosts that have GCC 8 (such as Ubuntu 18.10)
the GCC build bootstrap fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162
This is a fix that was applied to the upstream GCC 7 branch.
Change-Id: I7796d2a999ec420805dd1c6cf0a1ecba1de5a897
(From OE-Core rev: c17f5e7e954487ad3e97e26c3e0d31443d658d5a)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refresh 0014-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch
to also define GLIBC_DYNAMIC_LINKER relative to SYSTEMLIBS_DIR on riscv.
(From OE-Core rev: 12e859dfb70f8aae40edfd88b143b6c771f4e1a6)
Signed-off-by: Ricardo Salveti <ricardo@opensourcefoundries.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is especially needed when defaulting to hard-float ABI
Fixes errors e.g.
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
Fixes [YOCTO #12795]
(From OE-Core rev: 85981cbbf0ce48a6d82bc39248afa9540ca858d8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Originally these ARM specific EXTRA_OECONF options were applied to
both gcc for the target and gcc-cross. That lead to a compromise
being made: gcc on the target was configured to default to an ARM
architecture which was at least compatible with the target (but not
necessarily an exact match) and gcc-cross was configured default to
armv7a for both armv7a and armv7ve (to avoid gcc-cross rebuilds when
switching between the two).
However, when these ARM specific EXTRA_OECONF options were moved from
gcc-configure-common.inc into gcc-target.inc (ie they were made to
apply only to gcc on the target) the compromise no longer needed to
be made.
http://git.openembedded.org/openembedded-core/commit/?id=851937dde81de2a9ef54c5f19a78fb12fb82afd4
(From OE-Core rev: 3c368282741e9de1f96988e127b86a6a01b6a26f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apply patch from Taras Kondratiuk <takondra@cisco.com> to gcc 8.x too.
Normal gcc-cross has build-id feature enabled by default, so most of
target binaries has build-id. But libc (glibc, musl) doesn't have
build-id, because it is built with gcc-cross-initial.
Build-id is a useful feature, so enable it for gcc-cross-initial too.
(From OE-Core rev: f24308c95853bec5cfc9f0794b111c6afecbe768)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Normal gcc-cross has build-id feature enabled by default, so most of
target binaries has build-id. But libc (glibc, musl) doesn't have
build-id, because it is built with gcc-cross-initial.
Build-id is a useful feature, so enable it for gcc-cross-initial too.
(From OE-Core rev: ba69701dac785a220feffd6118718b1c9e733548)
Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the posibility to build using TCLIBC=newlib.
It allows users to build baremetal applications with the use of a
C library.
Newlib is a lightweight C library meant to be used on embedded systems,
it is meant to be easily portable for new platforms and to provide
basic functionality on them, by design, it provides stubs for some of
these core functions declared as weak, so they can be built correctly
and then linked against some other library which provides specifics
about the platform being used if need be, libgloss takes care of these
in some cases, but it can also be extended, this patch also allows the
user to easily add other libraries to it by adding them to
NEWLIB_EXTENDED for this specific reason.
(From OE-Core rev: 9f0570351a7b0877aa50efff5fe9a9ef368cb38f)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Newlib is a C library that is intended to be used on embedded systems.
It is a conglomeration of several library parts, all under free software
licenses that make them easily usable on embedded products.
Newlib provides a C library alternative that can run on baremetal, mainly
for resource constrained devices.
Libgloss is the BSP part of the C library, which can be easily modified
to port for new hardware platforms.
(From OE-Core rev: fe490ff829440b94124317759d856e2e2daf5047)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will solve the mcpu/march conflicts we get when -mcpu=cortex-a7
is passed on cmdline since it will become incompatible with default
ifuncs in libatomic which is using armv7-a
(From OE-Core rev: 015b0d8ed6aa766e8cc96d10218ac86a28728bf9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libssp is implemented fully in glibc as well as in musl
so we really do not need the gcc version of this library
except may be for mingw, where we keep it enabled anyway
gcc in OE is built with the knowledge that C library
already provides libssp implementation, we should therefore
not need the gcc implementation of same.
libssp_nonshared piece is a detail which is needed when gcc
is the compiler, in glibc this is part of libc_nonshared.a
already and libc_nonshared.a is linked always when linking
with -lc becuase libc.so in glibc is actually a linker script
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )
which automatically links in the needed runtime bits, this however
is not the case for musl, where core SSP APIs are implemented in full
but compiler specific runtime isn't, for this we add a new package
called libssp_nonshared which generate the needed runtime stub
and gcc is already carrying patch to link to libssp_nonshared.a
on musl
This should fix a long standing problem where static PIE executable
were not buildable with OE since it was conflicting SSP implementation
one from C library and the other one from gcc and we end up with
duplicate symbol errors during linking.
Backport a patch from trunk which enhances enable|disable-libssp
to not only disable building libssp but also not emit the gcc
specs to use it for subsequent linking when stack-protector options
are used on compiler cmdline
(From OE-Core rev: 6c14f99936f8c8c9b9d9f40a6b0c69675ea9a566)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 has been supported since GCC 5.1, sparc has been supported
since 4.9, and S390 since 7.1.
Also mark as broken entirely with musl.
(From OE-Core rev: 7d90d2a70f0184ad715e9917d3e7aa096cf98f79)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We allow to set LINKER_HASH_STYLE to be empty so this would fail
since --with-linker-hash-style needs an argument and cant be empty
(From OE-Core rev: e176ab07d1afbb5d7e80d39d49b0f68738509c18)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to patch fuzz, it was applied again, so the same code sequence was
repeated twice. Not sure if that caused any bugs, but certainly wasn't
the right thing to do.
(From OE-Core rev: e3a50788bfeabbde226e280803a01dd7f765b2bc)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix an internal compiler error on PPC from building a specific test:
$ $CC -S 7d-02.c
7d-02.c: In function â:
7d-02.c:11:5: internal compiler error: in copy_to_mode_reg, at explow.c:612
vec_st(v, i*16,p);
^~~~~~
The failure appears to happen on all optimizations levels as well.
(From OE-Core rev: dd4aaf3965b57fcfbf668ab09ac75ccd9e3b3a04)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whenever "-mno-sse" is used, "-mfpmath" should be set to 387.
The test case should be modified accordingly as below:
/* { dg-additional-options "-mno-sse -mfpmath=387 " { target { i?86-*-* x86_64-*-* } } } */
Original patch from: RAGHUNATH LOLUR <raghunath.lolur@kpit.com>
(From OE-Core rev: 978b804b92b069f8f5a75f3390697e94a1bf907f)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is already in gcc-7-branch
6e6c7fc1e1
Thanks nsz for noticing it
(From OE-Core rev: 3d9c32f31047e9fae289b45fcf733c5df1ddaceb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
(From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The static PIE patch was updated by Juro Bystricky <juro.bystricky@intel.com>
to work with gcc 7.3.
This update from the stable gcc 7 branch includes the retpoline
functionality which is useful to assist with recent security issues.
Two backported patches were dropped as they're included in 7.3.
(From OE-Core rev: a4c1ede6876ad6b84ab2b3bece14bf0afdc9d6b7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new name is much more consistent with what this actually means. We put
the pieces in place to rename everything a while back but looks like we
forgot to actually do it! Fix that now.
(From OE-Core rev: af9612f5d6b848fceea22d10ee964437299be776)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for all stages of the cross/target/canadian compilers
and without it (and with indirect gcc dependencies disabled), the steps
fail. Add missing dependencies.
(From OE-Core rev: e7be4aedd4f1e23c596a8cae0437bc5c187787e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove various build host references from packages:
libstdc++
libstdc++-staticdev
gcc-runtime-dbg
The references are removoved by correctly setting various compiler
-fdebug-prefix-map settings. There are two main issues:
The default DEBUG_PREFIX_MAP variable references WORKDIR, however,
gcc sources are in a shared folder (work-shared)/
Additionally, DWARF info seems to store symlink names but gcc
seems to resolve symlink names referenced in -fdebug-prefix-map.
(From OE-Core rev: 04748af752b7f9d79ee4add67141d6c891f3bdbe)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had 7.x around for long enough now that it should be tested and usable
everywhere, drop 6.4.
(From OE-Core rev: 2ec354f93101d85b4a3739368c8f0a96ec84c7d0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 6.x and 7.x gcc, libgfortran now needs libbacktrace. Enable building of this
so that libgfortran builds correctly.
[YOCTO #12394]
(From OE-Core rev: 2c2f20a9756eccafac776e45e319af7666e6da96)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch to fix miscompilation on mips64.
We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
The output of the command is like `systemctl show <xxx>', which is incorrect.
The problem is due to the miscompilation of gcc for mips64 platform, thus
backporting patch from upstream to fix this problem.
[YOCTO #12266]
(From OE-Core rev: cfa13e5c756849820644d86d1882602649db6a9c)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
The output of the command is like `systemctl show <xxx>', which is incorrect.
This patch is from gcc bugzilla's attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803
The patch hasn't been merged into gcc. But it does solve the above problem.
(From OE-Core rev: 3717c76eb24217c14a22f72fdd8732923729dee8)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use ucontext_t not struct ucontext in linux-unwind.h files.
Current glibc no longer gives the ucontext_t type the tag struct
ucontext, to conform with POSIX namespace rules. This requires
various linux-unwind.h files in libgcc, that were previously using
struct ucontext, to be fixed to use ucontext_t instead. This is
similar to the removal of the struct siginfo tag from siginfo_t some
years ago.
Backport of patches by Joseph Myers, taken from
https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=249957
[YOCTO #12083]
(From OE-Core rev: ec1c18d866c137b1fa523d0fcc29f65a28f59f44)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
