Este es el compilador cruzado RISC-V C y C ++. Admite dos modos de compilación: una cadena de herramientas ELF/NewLib genérica y una cadena de herramientas Linux-Elf/GLIBC más sofisticada.
Este repositorio usa submódulos, pero los submódulos obtendrán automáticamente a la demanda, por lo que no se necesita una actualización de submódulo --recursive o git submodule update --init --recursive
$ git clone https://github.com/riscv/riscv-gnu-toolchain
Advertencia: Git Clone toma alrededor de 6.65 GB de disco y tamaño de descarga
Se necesitan varios paquetes estándar para construir la cadena de herramientas.
En Ubuntu, ejecutar el siguiente comando debería ser suficiente:
$ sudo apt-get install autoconf automake autotools-dev curl python3 python3-pip libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev ninja-build git cmake libglib2.0-dev libslirp-dev
En Fedora/Centos/Rhel OS, la ejecución del siguiente comando debería ser suficiente:
$ sudo yum install autoconf automake python3 libmpc-devel mpfr-devel gmp-devel gawk bison flex texinfo patchutils gcc gcc-c++ zlib-devel expat-devel libslirp-devel
En Arch Linux, ejecutar el siguiente comando debería ser suficiente:
$ sudo pacman -Syyu autoconf automake curl python3 libmpc mpfr gmp gawk base-devel bison flex texinfo gperf libtool patchutils bc zlib expat libslirp
También disponible para usuarios de Arch en el AUR: https://aur.archlinux.org/packages/riscv-gnu-toolchain-bin
En MacOS, puede usar HomeBrew para instalar las dependencias:
$ brew install python3 gawk gnu-sed make gmp mpfr libmpc isl zlib expat texinfo flock libslirp
Al ejecutar las instrucciones en este ReadMe, use gmake en lugar de make para usar la versión recién instalada de Make. Para construir el GLIBC (Linux) en MacOS, deberá construir dentro de un sistema de archivos sensible al caso. El enfoque más simple es crear y montar una nueva imagen de disco con un formato de caja sensible. Asegúrese de que el punto de montaje no contenga espacios. Esto no es necesario para construir NewLib o GCC en MacOS.
Este proceso comenzará descargando alrededor de 200 MIB de fuentes aguas arriba, luego parche, construirá e instalará la cadena de herramientas. Si existe un caché local de las fuentes aguas arriba en $ (DISTDIR), se utilizará; La ubicación predeterminada es/var/caché/distfiles. Su computadora necesitará alrededor de 8 GIB de espacio en disco para completar el proceso.
Para construir el compilador cruzado de NewLib, elija una ruta de instalación (que sea escritable). Si elige, diga, /opt/riscv , entonces agregue /opt/riscv/bin a su PATH . Luego, simplemente ejecute el siguiente comando:
./configure --prefix=/opt/riscv
make
Ahora debería poder usar riscv64-desconocido-elfo-gcc y sus primos.
Nota: Si planea usar una biblioteca externa que reemplace la parte de NewLib (por ejemplo libgloss-htif ), lea las preguntas frecuentes.
Para construir el compilador cruzado de Linux, elija una ruta de instalación (que sea escritable). Si elige, diga, /opt/riscv , entonces agregue /opt/riscv/bin a su PATH . Luego, simplemente ejecute el siguiente comando:
./configure --prefix=/opt/riscv
make linux
La compilación predeterminada se dirige a RV64GC (64 bits) con GLIBC, incluso en un entorno de compilación de 32 bits. Para construir la cadena de herramientas RV32GC de 32 bits, use:
./configure --prefix=/opt/riscv --with-arch=rv32gc --with-abi=ilp32d
make linux
En caso de que prefiera Musl LIBC sobre GLIBC, configure como arriba y opte por make musl en lugar de make linux .
Las arquitecturas compatibles son RV32I o RV64I más extensiones estándar (A) Tomics, (M) ultiplicación y división, (f) Loat, (d) Oble, o (G) Eneral para MAFD.
ABIS compatibles son ILP32 (32 bits de flotación suave), ILP32D (Float dura de 32 bits), ILP32F (32 bits con precisión única en registros y doble en la memoria, solo uso de nicho), LP64 LP64F LP64D (igual pero pero con 64 bits de largo y punteros).
Para construir un compilador cruzado con soporte para 32 bits y 64 bits, ejecute el siguiente comando:
./configure --prefix=/opt/riscv --enable-multilib
Y luego make , make linux o make musl para el compilador cruzado basado en Linux GLIBC o Linux Musl LIBC, respectivamente.
El compilador Multilib tendrá el prefijo RISCV64-ONCHNOWN-Elfo o RISCV64-HOCKNOWN-LINUX-GNU- pero podrá dirigirse a los sistemas de 32 bits y 64 bits. Admitirá las opciones más comunes -march / -mabi , que se pueden ver utilizando la bandera --print-multi-lib en cualquier compilador cruzado.
Linux ToolChain tiene una opción adicional --enable-default-pie para controlar la habilitación de PIE predeterminada para GCC, que se deshabilita de forma predeterminada.
Para personalizar los idiomas habilitados, use la opción --with-languages= . Por ejemplo, si desea habilitar c,c++,fortran , use ./configure --with-languages=c,c++,fortran . Esta opción solo entra en vigencia para la cadena de herramientas GNU.
Las construcciones funcionan mejor si se instalan en un directorio vacío. Si construye una cadena de herramientas de flotación dura y luego intenta construir una cadena de herramientas de flotación suave con el mismo directorio-prefix, entonces los scripts de compilación pueden confundirse y salir con un error de enlazador quejándose de que el código de flotación duro no se puede vincular con código flotante suave. Eliminar primero la cadena de herramientas existente, o usar un prefijo diferente para la segunda compilación, evita el problema. Está bien construir una cadena de herramientas NewLib y una Linux con el mismo prefijo. Pero debe evitar construir dos Newlib o dos cadenas de herramientas de Linux con el mismo prefijo.
Si construye una cadena de herramientas de Linux en un sistema MacOS, o en un sistema de Windows utilizando el subsistema de Linux o CyGwin, debe asegurarse de que el sistema de archivos sea sensible a los casos. Una compilación en un sistema de archivos insensible a la caja fallará cuando se construya GLIBC porque los archivos *.os y *.OS se golpearán entre sí durante la compilación que eventualmente resulta en errores de enlace confusos.
CentOS (y RHEL) proporcionan versiones de herramientas de GNU antiguas que pueden ser demasiado viejas para construir una cadena de herramientas RISC-V. Hay un conjunto de herramientas alternativo proporcionado que incluye versiones actuales de las herramientas GNU. Este es el DevToolset proporcionado como parte del servicio de colección de software. Para obtener más información, consulte la URL DevToolset-7. Hay varias versiones del DevToolset que están disponibles, por lo que también puede probar otras versiones de ella, pero tenemos al menos un informe que funciona DevToolset-7.
Hay una serie de opciones adicionales que se pueden pasar para configurar. Ver './configure --help' para más detalles.
También puede definir indicadores adicionales para pasar a proyectos específicos: BINUTILS_NATIVE_FLAGS_EXTRA, BINUTILS_TARGET_FLAGS_EXTRA, GCC_EXTRA_CONFIGURE_FLAGS, GDB_NATIVE_FLAGS_EXTRA, GDB_TARGET_FLAGS_EXTRA, GLIBC_TARGET_FLAGS_EXTRA, NEWLIB_TARGET_FLAGS_EXTRA . Ejemplo: GCC_EXTRA_CONFIGURE_FLAGS=--with-gmp=/opt/gmp make linux
--with-isa-spec= puede especificar la versión predeterminada de la especificación ISA RISC-V sin privilegios (anteriormente a nivel de usuario).
Las opciones posibles son: 2.2 , 20190608 y 20191213 .
La versión predeterminada es 20191213 .
Más detalles sobre esta opción Puede consultar esta publicación Post RISC-V GNU Toolchain Strupping predeterminado ISA Spec a 20191213.
--with-multilib-generator= puede especificar qué multilibs construir. El argumento es una lista de valores separada por semicolon, posiblemente que consiste en un solo valor. Actualmente solo es compatible con RISCV* - -ELL . Los valores y significados aceptados se dan a continuación.
Cada configuración se construye con cuatro componentes: cadena de arquitectura, ABI, regla de reutilización con cadena de arquitectura y regla de reutilización con sub-extensión.
Reutilizar el operador de expansión de soporte de piezas (*) Para simplificar la combinación de diferentes subcensiones, el ejemplo 4 demuestra cómo usa y funciona.
Ejemplo 1: Agregue soporte de múltiples libras para RV32I con ILP32.
./configure --with-multilib-generator="rv32i-ilp32--"
Ejemplo 2: Agregue soporte de múltiples libras para RV32I con ILP32 y RV32IMAFD con ILP32.
./configure --with-multilib-generator="rv32i-ilp32--;rv32imafd-ilp32--"
Ejemplo 3: Agregar soporte de múltiples libras para RV32I con ILP32; RV32IM con ILP32 y RV32IC con ILP32 reutilizará este conjunto de múltiples libras.
./configure --with-multilib-generator="rv32i-ilp32-rv32im-c"
Ejemplo 4: agregue soporte de múltiples libras para RV64IMA con LP64; RV64IMAF con LP64, RV64IMAC con LP64 y RV64IMAFC con LP64 reutilizará este conjunto de múltiples libras.
./configure --with-multilib-generator="rv64ima-lp64--f*c"
La suite de prueba DeJagnu se ha portado a RISC-V. Esto se puede ejecutar con un simulador para las cadenas de herramientas ELF y Linux. El simulador se puede seleccionar mediante la variable SIM en MakeFile, por ejemplo, sim = qemu, sim = gdb o sim = spike (experimental). En adición, el simulador también se puede seleccionar con la opción Configurar tiempo --with-sim= Sin embargo, la lista de permiso TestSuite solo está acuñada para QEMU. Otros simuladores pueden obtener fallas adicionales.
Una secuencia de comandos auxiliar para configurar el entorno de prueba requiere pyelftools.
En las versiones más nuevas de Ubuntu, la ejecución del siguiente comando debería ser suficiente:
$ sudo apt-get install python3-pyelftools
En versiones más nuevas de Fedora y CentOS/Rhel OS (9 o posterior), la ejecución del siguiente comando debería ser suficiente:
$ sudo yum install python3-pyelftools
En Arch Linux, ejecutar el siguiente comando debería ser suficiente:
$ sudo pacman -Syyu python-pyelftools
Si su distribución/sistema operativo no tiene el paquete PyelfTools, puede instalarlo con PIP.
# Assuming that PIP is installed
$ pip3 install --user pyelftools
Para probar GCC, ejecute los siguientes comandos:
./configure --prefix=$RISCV --disable-linux --with-arch=rv64ima # or --with-arch=rv32ima
make newlib
make report-newlib SIM=gdb # Run with gdb simulator
./configure --prefix=$RISCV
make linux
make report-linux SIM=qemu # Run with qemu
./configure --prefix=$RISCV --with-sim=spike
make linux
make report # Run with spike
Nota:
Por defecto, GCC ejecutará todas las pruebas de su conjunto de pruebas de regresión. Mientras los ejecutaría en paralelo (por ejemplo, make -j$(nproc) report ) se acelerará significativamente el tiempo de ejecución en los sistemas de multiprocesador, el tiempo requerido para ejecutar todas las pruebas generalmente es demasiado alto para los ciclos de desarrollo típicos. Por lo tanto, GCC permite seleccionar las pruebas que se están ejecutando utilizando el entorno variable RUNTESTFLAGS .
Para restringir una ejecución de prueba solo a pruebas específicas de RISC-V, se puede usar el siguiente comando:
RunTestFlags = "Riscv.EXP" hacer un informe
Para restringir una ejecución de una prueba solo a las pruebas específicas de RISC-V con coincidir con el patrón "ZB*.C" y "SM*.C" El siguiente comando se puede usar:
RunTestFlags = "riscv.exp = zb*.c sm*.c" Haga un informe
El objetivo de makfile predeterminado para ejecutar las pruebas de cadena de herramientas es report . Esto ejecutará todas las pruebas de la suite de prueba de regresión GCC. Alternativamente, el siguiente comando se puede usar para hacer lo mismo:
make check-gcc
El siguiente comando se puede usar para ejecutar las pruebas de binutils:
make check-binutils
El siguiente comando se puede usar para ejecutar las pruebas GLIBC:
make check-glibc-linux
--with-extra-multilib-test se puede usar cuando desea probar más combinación de Arch/ABI, por ejemplo: construyó una cadena de herramientas de Linux con multilib con rv64gc/lp64d y rv64imac/lp64 , pero desea probar más configuración como la configuración como rv64gcv/lp64d o rv64gcv_zba/lp64d , entonces puede usar-with-extrra-multilib-test para especificar que a través de --with-extra-multilib-test="rv64gcv-lp64d;rv64gcv_zba-lp64d" , luego la prueba se ejecutará para rv64gc/lp64d , rv64imac/lp64 , rv64gcv/lp64d y rv64gcv_zba/lp64d .
--with-extra-multilib-test soporte de la cadena de herramientas de metal desnudo y linux y el soporte incluso multilib es deshabilitado, pero el usuario debe asegurarse de que la configuración de prueba multilib adicional pueda funcionar con Lib/multilib, por ejemplo, la prueba de RV32GCV/ILP32. Si Multilib no tuviera ningún RV32 Multilib.
--with-extra-multilib-test también admite un formato más complicado para adaptarse a los requisitos de los usuarios finales. En primer lugar, el argumento es una lista de configuraciones de prueba. Cada configuración de prueba está separada por ; . Por ejemplo:
rv64gcv-lp64d;rv64_zvl256b_zvfh-lp64d
Para cada configuración de prueba, tiene dos partes, también conocido como parte requerida de Arch-Abi y banderas de compilación opcionales. Aprovechamos : para separarlos con algunas restricciones.
: para separarlas. Por ejemplo: rv64gcv-lp64d:--param=riscv-autovec-lmul=dynamic:--param=riscv-autovec-preference=fixed-vlmax
se considerará como un tablero objetivo igual que a continuación:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=dynamic/--param=riscv-autovec-preference=fixed-vlmax
rv64gcv-lp64d:--param=riscv-autovec-lmul=dynamic,--param=riscv-autovec-preference=fixed-vlmax
se considerará como dos tableros objetivo igual que a continuación:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=dynamic
: :) o ( , ) operador juntos, pero el o ( , ) siempre tendrá la mayor prioridad. Por ejemplo: rv64gcv-lp64d:--param=riscv-autovec-lmul=dynamic:--param=riscv-autovec-preference=fixed-vlmax,--param=riscv-autovec-lmul=m2
se considerará como jabalíes Target Igual que a continuación:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=dynamic/--param=riscv-autovec-preference=fixed-vlmax
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m2
LLVM se puede usar en combinación con la cadena de herramientas del compilador RISC-V GNU para crear aplicaciones RISC-V. Para construir LLVM con C y C ++ admite el indicador Configurar --enable-llvm se puede usar.
Por ejemplo, para construir LLVM en la parte superior de una cadena de herramientas RV64 Linux Se pueden usar los siguientes comandos:
./configure --prefix = $ riscv --enable-llvm --enable-linux make
Tenga en cuenta que no es compatible una combinación de los indicadores de configuración --enable-llvm y multilib.
A continuación se muestran ejemplos sobre cómo construir una cadena de herramientas RV64GC Linux/NewLib con soporte LLVM, cómo usarlo para construir una aplicación C y una C ++ usando Clang, y cómo ejecutar los binarios generados usando QEMU.
Construir ejemplos de cadena de herramientas de Linux y ejecutar:
# Build rv64gc toolchain with LLVM
./configure --prefix=$RISCV --enable-llvm --enable-linux --with-arch=rv64gc --with-abi=lp64d
make -j$(nproc) all build-sim SIM=qemu
# Build C application with clang
$RISCV/bin/clang -march=rv64imafdc -o hello_world hello_world.c
$RISCV/bin/qemu-riscv64 -L $RISCV/sysroot ./hello_world
# Build C++ application with clang
$RISCV/bin/clang++ -march=rv64imafdc -stdlib=libc++ -o hello_world_cpp hello_world_cpp.cxx
$RISCV/bin/qemu-riscv64 -L $RISCV/sysroot ./hello_world_cpp
Cree ejemplos de NewLib Toolchain y ejecute (no funcione con --with-multilib-generator= ):
# Build rv64gc bare-metal toolchain with LLVM
./configure --prefix=$RISCV --enable-llvm --disable-linux --with-arch=rv64gc --with-abi=lp64d
make -j$(nproc) all build-sim SIM=qemu
# Build C application with clang
$RISCV/bin/clang -march=rv64imafdc -o hello_world hello_world.c
$RISCV/bin/qemu-riscv64 -L $RISCV/sysroot ./hello_world
# Build C++ application with clang using static link
$RISCV/bin/clang++ -march=rv64imafdc -static -o hello_world_cpp hello_world_cpp.cxx
$RISCV/bin/qemu-riscv64 -L $RISCV/sysroot ./hello_world_cpp
Esta sección es solo para desarrollador o usuario avanzado, o desea crear una cadena de herramientas con su propio árbol de origen.
riscv-gnu-toolchain contiene una fuente estable pero no más reciente para cada submódulo, en caso de que desee usar el último árbol Develoment, puede usar el siguiente comando para actualizar todo el submódulo.
git submodule update --remote
O puede actualizar solo un submódulo específico.
git submodule update --remote <component>
Por ejemplo, actualizar solo GCC, puede usar el siguiente comando:
git submodule update --remote gcc
La información de la rama se ha registrado en el archivo .gitmodules , que puede establecer o actualizar a través de git submodule add -b o git submodule set-branch .
Sin embargo, la única forma de verificar qué rama está utilizando es verificar el archivo .gitmodules , aquí está el ejemplo de gcc , está utilizando la sucursal de lanzamientos/GCC-12, por lo que Will tiene una sección llamada gcc y tiene una branch de campo releases/gcc-12 .
[submodule "gcc"]
path = gcc
url = ../gcc.git
branch = releases/gcc-12
riscv-gnu-toolchain riscv-gnu-toolchain también es compatible con el uso de una fuente fuera del árbol para construir la cadena de herramientas. Existen varias opciones de configuración para especificar el árbol de origen de cada submódulo/componente.
Por ejemplo, si tiene fuentes de GCC en $HOME/gcc , use --with-gcc-src para construir la cadena de herramientas utilizando esas fuentes:
./configure ... --with-gcc-src=$HOME/gcc
Aquí está la lista de opciones de configuración para especificar fuentes alternativas para los diversos submódulos/componentes:
--with-binutils-src
--with-dejagnu-src
--with-gcc-src
--with-gdb-src
--with-glibc-src
--with-linux-headers-src
--with-llvm-src
--with-musl-src
--with-newlib-src
--with-pk-src
--with-qemu-src
--with-spike-src
--with-uclibc-src
Las contribuciones del CCG deben cumplir con varios requisitos para calificar para la inclusión aguas arriba. La compilación gratuita de advertencia con una construcción de compiladores de las mismas fuentes está entre ellas. El flager --enable-host-gcc hace excluidos que:
-Werror para identificar problemas de códigoSi las partes de Newlib se reemplazarán con una biblioteca externa (como con Libgloss-HTIF para la interfaz de Target de host Berkeley), debe tener cuidado de asegurarse de que tanto NewLib como la biblioteca externa se construyan utilizando el mismo modelo de código. Para obtener más información sobre los modelos de código RISC-V, lea este artículo de Blog Sifive.
Los errores que indican un desajuste del modelo de código incluyen errores de "desbordamiento de reubicación" o "reubicación truncados" del enlazador que no se puede reubicar con éxito símbolos en el ejecutable.
Por defecto, riscv-gnu-toolchain construye NewLib con -mcmodel=medlow . Puede usar el modelo de código medany alternativo (como se usa en libgloss-htif) pasando --with-cmodel=medany al script de configuración.
