ARC GNU Tool Chain
This is the main Git repository for the ARC GNU toolchain. It contains just the scripts required to build the entire toolchain.
Branches in this repository are:
arc-releasesis the stable branch for the toolchain release. Head of this branch is a latest stable release. It is a branch recommended for most users
arc-stagingis the semi-stable branch for the toolchain release candidates. Head of this branch is either a latest stable release or latest release candidate for the upcoming release
arc-devis the development branch for the current toolchain release
While the top of development branches should build and run reliably, there
is no guarantee of this. Users who encountered an error are welcomed to create
a new bug report at GitHub Issues for this
The build script in this repository can be used for different versions of toolchain components, however such cross-version compatibility is not guaranteed.
The build script from this repository by default will automatically check out components to versions corresponding to the toolchain branch. Build script from development branch of toolchain repository will by default check out latest development branches of components. Build script from release and staging branches will check out components to the corresponding git tag. For example build script for 2020.03 release will checkout out components to arc-2020.03-release tag.
Linux-like environment is required to build GNU toolchain for ARC. To build a toolchain for Windows, it is recommended to cross-compile it using MinGW on Linux. Refer to "Building toolchain on Windows" section of this document.
Note that GDB requires compiler with C++ 11 support, therefore it is not possible to build toolchain with GCC 4.4 on RHEL/CentOS 6. Toolchain still can be built on RHEL/CentOS 6 when using manually installed newer compiler, however it is out of scope of this document to describe how to do that.
GNU toolchain for ARC has same standard prerequisites as an upstream GNU tool chain as documented in the GNU toolchain user guide or on the GCC website
On Ubuntu those can be installed with following command (as root):
# sudo apt-get update # sudo apt-get install -y texinfo byacc flex libncurses5-dev zlib1g-dev \ libexpat1-dev texlive build-essential git wget gawk bison xz-utils make \ python3 rsync locales
On CentOS/RHEL 6.x & 7.x those can be installed with following command:
# sudo yum install -y autoconf automake binutils bison byacc flex gcc \ gcc-c++ libtool patch texinfo-tex ncurses-devel ncurses-compat-libs \ flex zlib-devel expat-devel git texlive-collection-latexrecommended \ wget make xz rsync diffutils which
On Fedora & CentOS/RHEL 8.x+:
# sudo dnf install -y autoconf automake binutils bison byacc flex gcc \ gcc-c++ libtool patch texinfo-tex ncurses-devel ncurses-compat-libs \ flex zlib-devel expat-devel git texlive-collection-latexrecommended \ wget make xz rsync diffutils which
For building uClibc it is required to have
en_US.UTF-8 locale installed on the
build host (otherwise build fails, for details see https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/207). In case
en_US.UTF-8 is missing the following needs to be done:
Install package with locales. In case of Debian or Debian-based Linux distributions it is
Enable & generate
# sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && locale-gen
git package is required only if toolchain is being built from git
repositories. If it is built from the source tarball, then
git is not
Note: GNU binutils requires bison version 2, it doesn't work with bison 3. But glibc supports only bison >= 2.7. If you have bison 3 installed and toolchain build fails, try removing it.
It is not possible to build the Linux Glibc toolchain on CentOS 7 because glibc requires newer versions of Python and make than available in official repositories. It might be possible to install those dependencies manually or from 3rd party repositories. One of the options is to use so-called "Software Collections" (also known as "SCL") which is a community effort for providing more recent versions of core tools in both CentOS & Redhat distributions, see https://www.softwarecollections.org.
To get Python 3.x & GNU Make 4.2.1 installed on CentOS/RHEL 7.x the following commands should be executed:
# yum install -y centos-release-scl # yum install -y rh-python36 # yum install -y devtoolset-8-make # scl enable rh-python36 bash # scl enable devtoolset-8 bash
It has been observed that there is build failure on Ubuntu 17.10 - binutils compiled on that system refuses to accept valid input and that causes later failure when building the rest of the toolchain. This error wasn't observed on older Ubuntu versions, but it wasn't tested on newer Ubuntu versions.
GCC depends on the GMP, MPFR and MPC packages, however there are problems with
availability of those packages on the RHEL/CentOS 6 systems (packages has too
old versions or not available at all). To avoid this problem our build script
will download sources of those packages from the official web-sites. If option
--no-download-external is passed to the
build-all.sh script, when building
toolchain, then those dependencies will not be downloaded automatically,
instead versions of those libraries installed on the build host will be used.
In most cases this is not required.
By default HFS on macOS is configured to be case-insensitive, which is known to cause issues with Linux sources (there are files which differ only in character case). As a result to build uClibc toolchain for ARC it is required to use partition that is configured to be case sensitive (use Disk Utility to create a new partition, at least 16 GiB are needed to build uClibc toolchain, 32 GiB are needed to build a complete baremetal toolchain. With baremetal (elf) toolchain there are no such problems.
To build toolchain on macOS it is required to install several prerequisites which are either not installed by default or non-GNU-compatible versions are installed by default. This easily can be done with Homebrew:
# Install homebrew itself (https://brew.sh/) $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" # Install wget $ brew install wget # Install GNU sed $ brew install gnu-sed # Install xz, required to unpack GMP, MPC & MPFR tarballs. $ brew install xz
To build PDF documentation for toolchain TeX must be installed:
$ brew cask install mactex
If PDF documentation is not needed, pass option
--no-pdf to build-all.sh to
disable its build, then mactex is not required.
NB! Linux/uClibc toolchain built on macOS has different uClibc configuration then the one built on Linux hosts - locale support is disabled. The reason is that when locale support is enabled, uClibc makefiles will build an application called
genlocalethat will run on host system, but on macOS this application fails to build, therefore support for locales is disabled when Linux/uClibc toolchain is built on macOS.
GNU toolchain build process doesn't support source directories that contain whitespaces in it. Please make sure that ARC GNU source directory path doesn't contain any whitespaces.
Using source tarball
GNU Toolchain for ARC source tarball can be downloaded from project GitHub page https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases.
GNU toolchain source tarball already contains all of the necessary sources
except for Linux which is a separate product. Linux sources are required only
for Linux toolchain, they are not required for bare-metal elf32 toolchain.
Latest stable release from https://kernel.org/ is recommended, and only
versions >= 3.9 are supported. Linux sources should be located in the directory
linux that is the sibling of this
toolchain directory. For example:
$ wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.15.11.tar.xz $ tar xf linux-4.15.11.tar.xz --transform=s/linux-4.15.11/linux/
Using Git repositories
Source tarballs are available only for releases of GNU Toolchain. To build
toolchain from different components versions (for example from current trunk)
it is recommended to use Git.
Repositories for each of the toolchain components (its not all one big
repository), including the Linux repository, should be cloned before building
the toolchain. These should be peers of this
$ mkdir arc_gnu $ cd arc_gnu $ git clone https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain.git $ git clone https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb.git \ binutils $ git clone https://github.com/foss-for-synopsys-dwc-arc-processors/gcc.git $ git clone --reference binutils \ https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb.git gdb $ git clone https://github.com/foss-for-synopsys-dwc-arc-processors/newlib.git $ # For Linux uClibc toolchain: $ git clone https://github.com/wbx-github/uclibc-ng.git $ # or for Linux glibc toolchain: $ git clone https://github.com/foss-for-synopsys-dwc-arc-processors/glibc.git $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \ linux
The binutils and gdb share the same repository, but must be in separate
directories, because they use different branches. Option
when cloning gdb repository will tell Git to share internal Git files between
binutils and gdb repository. This will greatly reduce amount of disk space
consumed and time to clone the repository.
Note that it is possible to save disk space and time to fetch sources by using
--depth=1 - Git will not fetch the whole history of repository and
will instead only fetch the current state. This option should be accompanied by
-b <branch> option so that Git will fetch a state of required
branch or a tag. If branch is used, then current branches can be found in the
Note, however that if
build-all.sh will try to checkout repositories to their
latest state, which is a default behaviour, then it will anyway fetch
additional branches and tags, due to usage of
git fetch --all --tags. To
avoid this problem, pass
--no-auto-pull --no-auto-checkout to
- in this case it will leave Git repositories alone, leaving control in the hands of the user.
toolchain repository will be checked out to the current
If current working directory is not a "toolchain" directory, then change to it:
$ cd toolchain
This repository can be checked out to a specific GNU Toolchain for ARC release by specifying a particular release tag, for example for 2020.03 release that would be:
$ git checkout arc-2020.03-release
Building the Toolchain
build-all.sh will build and install both arc*-elf32- and
arc*-snps-linux-uclibc- toolchains. The comments at the head of this script
explain how it works and the parameters to use.
arc-versions.sh checks out each component Git repository to a
specified branch. Branches to checkout are specified in files in
directory. Which file is default depends on current
arc-dev branch default to
config/arc-dev.sh file, while
arc-staging will default to a file corresponding to a particular release or
release candidate. Default choice of
config file can be overridden with
--checkout-config option of
After checking out correct branches
build-all.sh in turn uses
build-uclibc.sh. These build respectively the
arc*-elf32 and arc*-snps-linux-uclibc toolchains. Details of the operation
are provided as comments in each script file. Both these scripts use a common
The most important options of
--install-dir <dir>- define where toolchain will be installed.
--glibc- choose type of toolchain to build. By default elf32 and uclibc are built. Specify
--no-uclibcif you intend to work exclusively with bare metal applications, specify
--no-elf32of you intend to work exclusively with Linux applications. Specify
--glibcif you want to build glibc toolchain instead of uClibc. Linux kernel is built with uClibc or glibc toolchain.
--no-multilib- do not build multilib standard libraries. Use it when you are going to work with bare metal applications for a particular core. This option does not affect uClibc toolchain.
--cpu <cpu>- configure GNU toolchain to use specific core as a default choice (default core is a core for which GCC will compile for when
-mcpu=option is not passed). Default is arc700 for both bare metal and Linux tool chains. Combined with
--no-multilibthis option allows to build GNU toolhain that supports only one specific core. Valid values depend on what is available in GCC As of version 2016.03 values available in ARC GCC are:
arc700. Note that only ARC 700 and ARC HS can be selected as a default core for Linux toolchain.
--host <triplet>- option to set host triplet of toolchain. That allows to do Canadian cross-compilation, where toolchain for ARC processors (
--target) will run on Windows hosts (
--host) but will be built on Linux host (
Please consult head of the
./build-all.sh file to get a full list of
supported options and their detailed descriptions.
--target-cflags options. They allow to build toolchain
tailored for a particular core. Option
--cpu will change default CPU of GCC.
--target-cflags on the other hand will change only CFLAGS used to
compile toolchain standard library, but will not affect default compiler
options. Consequently, when using a toolchain configured this way it still will
be required to provide corresponding compiler options except for the
--target-cflags sets C[XX]FLAGS_FOR_TARGET. Those two variables
override default C[XX]FLAGS of standard libraries which are "-O2 -g". Hence to
specify custom architecture flags, but preserve optimizations it is required to
pass optimization flags to --target-cflags as well. Libraries optimized for
size will override any -Ox flag passed via --target-cflags, while other flags
will not be overridden.
Build options examples
This command will build default toolchain - bare metal toolchain will support all ARC cores, while Linux toolchain will support ARC 700:
$ ./build-all.sh --install-dir $INSTALL_ROOT
This command will build toolchain for ARC 700 Linux development:
$ ./build-all.sh --no-elf32 --install-dir $INSTALL_ROOT
This command will build toolchain for ARC HS Linux development:
$ ./build-all.sh --no-elf32 --cpu hs38 --install-dir $INSTALL_ROOT
This command will build toolchain for ARC HS Linux development with glibc:
$ ./build-all.sh --no-elf32 --glibc --cpu hs38 --install-dir $INSTALL_ROOT
This command will build bare metal toolchain for ARC EM7D in the ARC EM Starter Kit 2.3:
$ ./build-all.sh --no-uclibc --install-dir $INSTALL_ROOT --no-multilib \ --cpu em4_dmips
This command will build bare metal toolchain for ARC EM9D in the ARC EM Starter Kit 2.3:
$ ./build-all.sh --no-uclibc --install-dir $INSTALL_ROOT --no-multilib \ --cpu em4_fpus --target-cflags "-O2 -g -mfpu=fpus_all"
This command will build bare metal toolchain for ARC EM11D in the ARC EM Starter Kit 2.3:
$ ./build-all.sh --no-uclibc --install-dir $INSTALL_ROOT --no-multilib \ --cpu em4_fpuda --target-cflags "-O2 -g -mfpu=fpuda_all"
To build native ARC Linux uClibc toolchain (toolchain that runs on same system as for
which it compiles, so host == target) it is required first to build a normal
cross toolchain for this system. Then it should be added it to the PATH, after
build-all.sh can be run:
$ ./build-all.sh --no-elf32 --install-dir $INSTALL_ROOT_NATIVE \ --cpu hs38 --native --host arc-snps-linux-uclibc
In this command line, argument to
--cpu option must correspond to the target
CPU and argument to
--host options depends on whether this is a big or little
endian target. Install directory must be different than the one where
cross-toolchain is installed.
Building toolchain on Windows
To build toolchain for Windows hosts it is recommended to do a "Canadian cross-compilation" on Linux, that is toolchain for ARC targets that runs on Windows hosts is built on Linux host. Build scripts expect to be run in Unix-like environment, so it is often faster and easier to build toolchain on Linux, than do this on Windows using environments like Cygwin and MSYS. While those allow toolchain to be built on Windows natively this way is not officially supported and not recommended by Synopsys, due to severe performance penalty of those environments on build time and possible compatibility issue.
Some limitation apply:
- Only bare metal (elf32) toolchain can be built this way.
- It is required to have toolchain for Linux hosts in the
PATHfor Canadian cross-build to succeed - it will be used to compile standard library of tool chain.
- Expat library is required for GDB to parse XML target description files. This
library might be not available in some Mingw setup. Easiest solution is to
build-all.shscript to build Expat by passing option
To cross-compile toolchain on Linux, Mingw toolchain should be installed. On
Ubuntu that can be done with
# apt-get install mingw-w64
CentOS 6 has a very antique Mingw (4.4-something), so it is recommended to first add EPEL repository, then install Mingw from it. In CentOS:
# yum install epel-release # yum install mingw-binutils-generic mingw-filesystem-base \ mingw32-binutils mingw32-cpp mingw32-crt mingw32-filesystem mingw32-gcc \ mingw32-gcc-c++ mingw32-headers mingw32-winpthreads \ mingw32-winpthreads-static
For instruction how to install EPEL on CentOS, see https://fedoraproject.org/wiki/EPEL/FAQ.
First stage of GCC build should be disabled, because libraries will be built with the Linux host toolchain.
After prerequisites are installed do:
$ export PATH=$LINUX_HOST_TOOLS_PATH/bin:$PATH $ ./build-all.sh --no-uclibc --host i686-w64-mingw32 \ --no-system-expat --no-elf32-gcc-stage1
Note that value of host triplet depends on what mingw toolchain is being used.
i686-w64-mingw32 is valid for mingw toolchain currently used in
Ubuntu and EPEL, but, for example, mingw toolchain in standard CentOS 6 has
In all of the following examples it is expected that GNU toolchain for ARC has been added to the PATH:
$ export PATH=$INSTALL_ROOT/bin:$PATH
Using nSIM simulator to run bare metal ARC applications
nSIM simulator supports GNU IO hostlink used by the libc library of bare metal
GNU toolchain for ARC. nSIM option
nsim_emt=1 enables GNU IO hostlink.
To start nSIM in gdbserver mode for ARC EM6:
$ $NSIM_HOME/bin/nsimdrv -gdb -port 51000 \ -tcf $NSIM_HOME/etc/tcf/templates/em6_gp.tcf -on nsim_emt
And in second console (GDB output is omitted):
$ arc-elf32-gcc -mcpu=arcem -g --specs=nsim.specs hello_world.c $ arc-elf32-gdb --quiet a.out (gdb) target remote :51000 (gdb) load (gdb) break main (gdb) break exit (gdb) continue (gdb) continue (gdb) quit
GDB also might execute commands in a batch mode so that it could be done automatically:
$ arc-elf32-gdb -nx --batch -ex 'target remote :51000' -ex 'load' \ -ex 'break main' -ex 'break exit' \ -ex 'continue' -ex 'continue' -ex 'quit' a.out
If one of the HS TCFs is used, then it is required to add
-on nsim_isa_ll64_option to nSIM options, because GCC for ARC automatically
generates double-world memory operations, which are not enabled in TCFs
supplied with nSIM:
$ $NSIM_HOME/bin/nsimdrv -gdb -port 51000 \ -tcf $NSIM_HOME/etc/tcf/templates/hs36.tcf -on nsim_emt \ -on nsim_isa_ll64_option
nSIM distribution doesn't contain big-endian TCFs, so
-on nsim_isa_big_endian should be added to nSIM options to simulate big-endian
$ $NSIM_HOME/bin/nsimdrv -gdb -port 51000 \ -tcf $NSIM_HOME/etc/tcf/templates/em6_gp.tcf -on nsim_emt \ -on nsim_isa_big_endian
Default linker script of GNU Toolchain for ARC is not compatible with memory maps of cores that only has CCM memory (EM4, EM5D, HS34), thus to run application on nSIM with those TCFs it is required to link application with linker script appropriate for selected core.
When application is simulated on nSIM gdbserver all input and output happens on the side of host that runs gdbserver, so in "hello world" example string will be printed in the console that runs nSIM gdbserver.
Note the usage of
nsim.specs specification file. This file specifies that
applications should be linked with nSIM IO hostlink library libnsim.a, which is
implemented in libgloss - part of newlib project. libnsim provides several
functions that are required to link C applications - those functions a
considered board/OS specific, hence are not part of the normal libc.a. To link
application without nSIM IO hostlink support use
nosys.specs file - note that
in this case system calls are either not available or have stub
implementations. One reason to prefer
nosys.specs even when
developing for hardware platform which doesn't have hostlink support is that
nsim will halt target core on call to function "exit" and on many errors,
nosys.specs is an infinite loop. For more details
please see documentation.
Using EM Starter Kit to run bare metal ARC EM application
A custom linker script is required to link applications for EM Starter Kit. Refer to the section "Building application" of our EM Starter Kit page: http://embarc.org/toolchain/baremetal/em-starter-kit.html
Build instructions for OpenOCD are available at its page: https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/arc-0.9-dev-2017.09/doc/README.ARC
To run OpenOCD:
$ openocd -f /usr/local/share/openocd/scripts/board/snps_em_sk_v2.3.cfg
Compile test application and run:
$ arc-elf32-gcc -mcpu=em4_dmips -g --specs=emsk_em9d.specs simple.c $ arc-elf32-gdb --quiet a.out (gdb) target remote :3333 (gdb) load (gdb) break main (gdb) continue (gdb) step (gdb) next (gdb) break exit (gdb) continue (gdb) quit
Using Ashling Opella-XD debug probe to debug bare metal applications
A custom linker script is required to link applications for EM Starter Kit. Refer to the section "Building application" of our EM Starter Kit page: http://embarc.org/toolchain/baremetal/em-starter-kit.html For different hardware configurations other changes might be required.
The Ashling Opella-XD debug probe and its drivers are not part of the GNU tools distribution and should be obtained separately.
The Ashling Opella-XD drivers distribution contains gdbserver for GNU tool chain. Command to start it:
$ ./ash-arc-gdb-server --jtag-frequency 8mhz --device arc \ --arc-reg-file <core.xml>
Where <core.xml> is a path to XML file describing AUX registers of target core.
The Ashling drivers distribution contain files for ARC 600 (arc600-core.xml)
and ARC 700 (arc700-core.xml). However due to recent changes in GDB with
regards of support of XML target descriptions those files will not work out of
the box, as order of some registers changed. To use Ashling GDB server with GDB
starting from 2015.06 release it is required to use modified files that can be
found in this
toolchain repository in
Before connecting GDB to an Opella-XD gdbserver it is essential to specify
path to XML target description file that is aligned to
<core.xml> file passed
to GDB server. All registers described in
<core.xml> also must be described
in XML target description file in the same order. Otherwise GDB will not
(gdb) set tdesc filename <path/to/opella-CPU-tdesc.xml>
XML target description files are provided in the same
directory as Ashling GDB server core files.
Then connect to the target as with the OpenOCD/Linux gdbserver. For example a full session with an Opella-XD controlling an ARC EM target could start as follows:
$ arc-elf32-gcc -mcpu=arcem -g --specs=nsim.specs simple.c $ arc-elf32-gdb --quiet a.out (gdb) set tdesc filename toolchain/extras/opella-xd/opella-arcem-tdesc.xml (gdb) target remote :2331 (gdb) load (gdb) break main (gdb) continue (gdb) break exit (gdb) continue # Register R0 contains exit code of function main() (gtb) info reg r0 (gdb) quit
Similar to OpenOCD hostlink is not available in GDB with Ashling Opella-XD.
Debugging applications on Linux for ARC
$ arc-linux-gcc -g -o hello_world hello_world.c
Copy it to the NFS share, or place it in rootfs, or make it available to target system in any way other way. Start gdbserver on target system:
[ARCLinux] # gdbserver :51000 hello_world
Start GDB on the host:
$ arc-linux-gdb --quiet hello_world (gdb) set sysroot <buildroot/output/target> (gdb) target remote 192.168.218.2:51000 (gdb) break main (gdb) continue (gdb) continue (gdb) quit
Testing the toolchain
run-tests.sh will run the regression test suites against all the
main toolchain components. The comments at the head of this script explain
how it works and the parameters to use. It in turn uses the run-elf32-tests.sh
and run-uclibc-tests.sh scripts.
You should be familiar with DejaGnu testing before using these scripts. Some
configuration of the target board specifications (in the
directory) may be required for your particular test target.