There are some fixes to the cmse code in mainline gcc that we need to
build an embedded toolchain targetting Cortex-M cpus that support the
v8m extensions.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
gcc-8.1 for xtensa miscompiles uClibc dynamic linker due to gcc PR
target/65416. The build completes successfully, but the binary is
non-functional because the following fragment in the _dl_get_ready_to_run
in ld-uClibc.so overwrites register spill area on stack causing register
corruption in the previous call frame and a subsequent crash:
419f: f0c1b2 addi a11, a1, -16
41a2: 1ba9 s32i.n a10, a11, 4
41a4: 0bc9 s32i.n a12, a11, 0
41a6: 5127f2 l32i a15, a7, 0x144
41a9: 1765b2 s32i a11, a5, 92
41ac: 4e2782 l32i a8, a7, 0x138
41af: 146af2 s32i a15, a10, 80
41b2: 001b10 movsp a1, a11
The crash terminates the init process and causes kernel panic.
The fix prevents reordering of movsp opcode and any access to the stack
frame memory and is applicable to all existing gcc versions.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
We never bothered to build multilibbed Linux toolchains for ARC
and so we ended-up with no support of multilib for arc*-*-linux-*
targets in GCC. That is now fixed in upstream by the following commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0eacfbcb2bf1834294f468a2bb41fe5d5e8d3883
Once the fix mentioned above is applied on top of GCC 8.1.0 we may easily build
multilibbed uClibc toolchain for ARC.
Note sice Glibc port for ARC is still in review process we cannot build any Glibc
toolchains for ARC with pure upstream components, for that we eiter need Glibc
sources from our Github repo or apply a set of patches on top of Glibc 2.27 - we'll
try to address this later though.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
hs4x and hs4xd were mistakenly mentioned in MULTILIB_OPTION/DIRNAMES
before real support of those CPUs was accepted in upstream.
That breaks multilib toolchains building becase we're trying to compile
for not yet known CPU.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Without this fix we're getting the following error on attempt to build
Linux kernel:
--------------------------------->8---------------------------------
xfrm4_mode_tunnel.s: Assembler messages:
xfrm4_mode_tunnel.s:188: Error: operand out of range (128 is not between -
128 and 127)
--------------------------------->8---------------------------------
The fix is taken from
d8d716f49c
and it is supposed to be merged in upstream GCC sources soonish.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
- Incompatible function type for ifunc alias
- Multiple statements macro expansion in strftime
- if_nametoindex size checking
Signed-off-by: Alexey Neyman <stilor@att.net>
- GLIBC requires a fix to work with binutils 2.30 on aarch64. This fix
relies on binutils 2.24 or newer, which is okay for glibc 2.26 since
it needs 2.25 or newer anyway. But older glibc versions are now pinned
to binutils 2.29 or older on aarch64.
- xtensa needs patches in libgcc with gcc 7.3.
- comment in newlib's patch to indicate it is a reversal of a commit.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Update to 20180129
- Throw in --disable-db-install if database is disabled; otherwise
'make install' tries to run tic which is not built.
- Select appropriate strip utility for the host; otherwise non-x86
architectures fail to install (unless --disable-stripping is also
added)
Signed-off-by: Alexey Neyman <stilor@att.net>
android-ndk, binutils, gcc, linux, mpfr, ncurses, newlib, uclibc-ng
MPC vs MPFR dependencies required modifications in auto-generated templates
to also provide non-inclusive older-than/newer-than specifications.
Also correct MPC URLs, the website seems to have adjusted its directory
layout.
Currently, newlib 3.0.0 doesn't build for arm-nano-eabi.
Signed-off-by: Alexey Neyman <stilor@att.net>
