crosstool-ng/scripts/build/arch/arc.sh
Alexey Brodkin 028c372ba6 ARC: No more fiddling with uClibc's CONFIG_ARC_HAS_ATOMICS
Older ARC700 processors had atomic instructions (AKA llock/scond)
as an option and so quite some "atomic" operations were not possible
w/o OS support, which we implemented - see arc_usr_cmpxchg() in the
Linux kernel.

And in uClibc, which was the only Linux libc back in the day of ARC700
era, it is well supported. Well, uClibc could be configured to support it.
Which is done with CONFIG_ARC_HAS_ATOMICS Kconfig option.

But the problem is there's no check for ARC ISA version in uClibc when
this option gets enabled. That leads to a funny situation when even for
ARCv2 processors (ARC HS3x & HS4x) uClibc tries to utilize
arc_usr_cmpxchg() syscall which is not supported for this newer ISA since
ARCv2 processors have atomic instructions built-in all the time.

So what was happening here we didn't specify additional "-matomic"
CFLAG unless we were targeting exactly those ancient ARC770 processors
(ARC700 + MMUv3 + atomics) and so even for ARCv2 we forced uClibc
to not use built-in atomics.

And even though there're ways to add a smarter solution here to handle
that pretty rare by now case of ARC750 (ARC700 + MMUv2 - atomics),
I suggest we just remove this part completely, leaving a possibility
to add needed option in uClibc-ng's configuration
(I mean "packages/uClibc-ng/config").

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2021-08-24 09:48:56 -07:00

51 lines
1.4 KiB
Bash

# Compute ARC-specific values
CT_DoArchTupleValues()
{
# The architecture part of the tuple:
CT_TARGET_ARCH="${CT_ARCH}${CT_ARCH_SUFFIX:-${target_endian_eb}}"
}
CT_DoArchUClibcConfig()
{
local cfg="${1}"
CT_DoArchUClibcSelectArch "${cfg}" "arc"
}
# Multilib: Adjust configure arguments for GLIBC
# Usage: CT_DoArchGlibcAdjustConfigure <configure-args-array-name> <cflags>
#
# From GCC's standpoint ARC's multilib items are defined by "mcpu" values
# which we have quite a few and for all of them might be built optimized
# cross-toolchain.
#
# From Glibc's standpoint multilib is multi-ABI and so very limited
# versions are supposed to co-exist.
#
# Here we force Glibc to install libraries in per-multilib folder to create
# a universal cross-toolchain that has libs optimized for multiple CPU types.
CT_DoArchGlibcAdjustConfigure() {
local -a add_args
local array="${1}"
local cflags="${2}"
local opt
local mcpu
# If building for multilib, set proper installation paths
if [ "${CT_MULTILIB}" = "y" ]; then
for opt in ${cflags}; do
case "${opt}" in
-mcpu=*)
mcpu="${opt#*=}"
add_args+=( "libc_cv_rtlddir=/lib/${mcpu}" )
add_args+=( "libc_cv_slibdir=/lib/${mcpu}" )
add_args+=( "--libdir=/usr/lib/${mcpu}" )
;;
esac
done
fi
eval "${array}+=( \"\${add_args[@]}\" )"
}