They're written in ARM dialect, and `ldmia r14, {r14, pc}` is not accepted in T2
encoding. GCC8 changed the list of multilibs for arm-*, which now includes a
variant with CPU that supports T2 but not A1 encoding.
Signed-off-by: Alexey Neyman <stilor@att.net>
There's no point in keeping samples which are in its essense
just a sub-set of multilib toolchain.
But still we'd like to cover quite unusual but really existing
case - ARC750, i.e. ARC700 with MMU but without so-called
atomic instructions (LLOCK/SCOND). To support this HW variation
we need:
1) Compile all target binaries without "-matomics" or even
better "-mno-atomics" so that's even future-proof
(as we may decide to enable "-matomics" by default for Linux
targets which is a recommented setup).
2) Configure libc such that it uses Linux-kernel-assisted implementation
of atomic operation via "arc_usr_cmpxchg" syscall,
see https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=b985fa069187e4c5a7ee84213d9fbead2f219ce5
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
In case we build for ARC core which has no support of atomic ops among
other things we need to configure libc to use Linux kernel helper to emulate
HS atomic ops. This is done with disabling of CONFIG_ARC_HAS_ATOMICS in uClibc.
Currently we __remove__ this option from .config but this makes no sense as
its default state is "y" so we need to explicitly disable it instead.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.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>
Synopsys' DesignWare ARC Processors are a family of 32-bit CPUs
that SoC designers can optimize for a wide range of uses,
from deeply embedded to high-performance host applications in a variety
of market segments.
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>
... in the corresponding /lib directory. Mingw-w64 installs it to /bin,
so multiple variants in a multilib configuration override each other.
Signed-off-by: Alexey Neyman <stilor@att.net>
Also, build containers with --no-cache: distributions like ArchLinux
retire their packages very quickly, need to always use up-to-date
package databases.
Signed-off-by: Alexey Neyman <stilor@att.net>
... which now defaults to --enable-mpers=yes, which attempts to
invoke aarch64-*-gcc with -m32 and fails.
Signed-off-by: Alexey Neyman <stilor@att.net>
