NOTE: This is toolchain developer facing feature.
This allow user to add extra testing multi-lib arch, it's useful when
develop and/or testing new extensions.
Usage:
--with-extra-multilib-test="arch-abi[;arch-abi]"
e.g.
linux enable enabled multilib, so default will build with follwoing
configuration:
lib32/ilp32;@march=rv32imac@mabi=ilp32
lib32/ilp32d;@march=rv32imafdc@mabi=ilp32d
lib64/lp64;@march=rv64imac@mabi=lp64
lib64/lp64d;@march=rv64imafdc@mabi=lp64d
But you want to testing more on vector stuffs like rv32gcv and rv64gcv,
then you can configure with `--with-extra-multilib-test="rv32gcv-ilp32d;rv64gcv;lp64d"`
Then the testing will run rv32imac-ilp32 rv32imafdc-ilp32d
rv64imac-lp64 rv64imafdc-lp64d and rv32gcv-ilp32d;rv64gcv;lp64d!
NOTE: Extra multilib test settings still require existing
multilib has support those extra settings, e.g. you can't add
rv32imafc_zbb-ilp32f on above example since no compatible multilib has
provided.
We currently have a stale "llvm" branch, that does not build.
However, there is clear demand in the RISC-V toolchain community
for a working LLVM on top of a recent GNU toolchain.
In order to build such a toolchain, quite some LLVM and clang know-how is
required to avoid path issues at LLVM build time or later when using clang.
The main purpose of this commit is to demonstrate a way to combine
the RISC-V GNU toolchain repo with LLVM, with the intent to save
others hours of frustration, debugging time or support time.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Using llvm-objdump I found warning if file was
compiled using riscv-gcc. Examples:
warning: failed to find source riscv-glibc/csu/elf-init.c
It concerned with compilation glibc with
debug info that is unnecessary operation. If user want to have debug info, than it's easy to pass -g.
This option wasn't touched more than 7 years...
We have this feature for all other packages.
It is particularly useful to avoid pointless internet downloads
for automatic builds.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
GDB still defaults to 10.1 from the (already archived)
riscv-binutils-gdb repo. Let's bump the version to 12.1
and use the upstream git repo instead.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
I'm trying to clean up some of my test scripts, and one issue is that
I've got two QEMU builds: one for user-mode emulation and one for
system-mode emulation. This adds an autoconf flag that allows me to
avoid the duplication.
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This lets users select whether or not to build libsanitizer, which
currently does not support rv32 and thus can't be enabled by default.
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
The upstream musl libc does not support 32bit RISC-V builds.
We therefore only allow building the 64bit version (i.e.,
riscv64-unknown-linux-musl-).
Signed-off-by: Florian Hofhammer <florian.hofhammer@fhofhammer.de>
Since musl is already incorporated into the build system (see for
example configure.ac, Makefile.in), this patch adds a submodule for
musl based on the current v1.2.2 release.
The GitHub Actions configurations have also been updated to include
the musl based toolchain.
Signed-off-by: Florian Hofhammer <florian.hofhammer@fhofhammer.de>
Both the glibc and newlib submodules are already pointing to the
upstream repositories where development happens.
Since they are therefore not referring to RISC-V specific forks,
this patch unifies the directory naming by only prepending the
"riscv-" prefix to submodules that point to repositories in the
riscv-collab Github organization.
Signed-off-by: Florian Hofhammer <florian.hofhammer@fhofhammer.de>
The recent addition of an override for the QEMU source directory left
the default pointing to the wrong submodule.
Fixes: b83ee52 ("Allow source-override for QEMU")
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
This patch introduces a configure-time source-dir override for QEMU
similar to the existing overrides for the other toolchain sources.
Signed-off-by: Christoph Muellner <cmuellner@linux.com>
We need this to have different polarity for different platforms (Windows
vs RedHat). I don't know how to autodetect this for now, so I'm just
doing it manually.
Soft-float calling convention is default, but an alternate hard-float
calling convention (with doubles passed as in soft-float, but floats
passed as in hard-float) is supported.
Augment the handling of --with-arch such that it can properly set XLEN,
atomics flags, and floating point flags. The original
--enable-atomics/float flags are still respected, but if --with-arch is
provided then it supersedes other options.
It's no longer the case that building the toolchain with
"--disable-float" turns off floating-point by default. This passes the
correct arguments to all the various sub-configures in order to ask for
floating-point support to be either enabled or disabled.