| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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 just multi-ABI [1] and so very limited
versions are supposed to co-exist (e.g. arc700 & archs).
Here we force Glibc to install libraries in GCC's multilib folder to create
a universal cross-toolchain that has libs optimized for multiple CPU types.
But note we only need to mess with installation paths in case of real
multilib, otherwise we keep default "lib/" paths so that GCC finds default
(the one and only) libs where it expects them to be.
Also here we add a sample which allows to build universal Glibc Linux
toolchain for ARC.
[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00018.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
... parts of the config tuple. While here, remove parts that are
setting portions of the target tuple to a value that's already
the default.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
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>
|
|
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>
|
Alexey Brodkin
Alexey Neyman