riscv-gnu-toolchain | GNU toolchain for RISC-V , including GCC | Compiler library

by riscv C Version: 2021.08.11 License: Non-SPDX

X-Ray Key Features Code Snippets Community Discussions(8)Vulnerabilities Install Support

kandi X-RAY | riscv-gnu-toolchain Summary

riscv-gnu-toolchain is a C library typically used in Utilities, Compiler applications. riscv-gnu-toolchain has no bugs, it has no vulnerabilities and it has medium support. However riscv-gnu-toolchain has a Non-SPDX License. You can download it from GitHub.

This is the RISC-V C and C++ cross-compiler. It supports two build modes: a generic ELF/Newlib toolchain and a more sophisticated Linux-ELF/glibc toolchain.

Support

Quality

Security

License

Reuse

Support

riscv-gnu-toolchain has a medium active ecosystem.

It has 1222 star(s) with 533 fork(s). There are 116 watchers for this library.

It had no major release in the last 12 months.

There are 155 open issues and 490 have been closed. On average issues are closed in 8 days. There are 1 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of riscv-gnu-toolchain is 2021.08.11

Quality

riscv-gnu-toolchain has 0 bugs and 0 code smells.

Security

riscv-gnu-toolchain has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

riscv-gnu-toolchain code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

riscv-gnu-toolchain has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

riscv-gnu-toolchain releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of riscv-gnu-toolchain

Get all kandi verified functions for this library.

riscv-gnu-toolchain Key Features

No Key Features are available at this moment for riscv-gnu-toolchain.

riscv-gnu-toolchain Examples and Code Snippets

No Code Snippets are available at this moment for riscv-gnu-toolchain.

Community Discussions

Trending Discussions on riscv-gnu-toolchain

compiling multithreading C example with riscv gnu cross compiler

How to cross-compile elfutils for RISC-V?

Connecting linker script with assembly file [risc-v]

How to prevent GCC from inserting memset during link-time optimization?

RISC V linker cannot find -lgcc

Linker error : undefined reference to _fbss

How can get g++ to use my own glibc build's headers correctly?

RISC-V ecall syscall calling convention on pk/Linux

QUESTION

compiling multithreading C example with riscv gnu cross compiler

Asked 2022-Jan-10 at 19:24

I'm using homebrew-riscv toolchain on mac machine.

I want to compile a simple multithreading program that is written using pthread library in C using riscv gnu cross compiler. So that, I've used the below command:

riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 pthreadExample.c -o pthreadExample -lpthread

And I've got the following warning and error:

...

ANSWER

Answered 2022-Jan-10 at 19:24

you are using the bare metal cross compiler, what you need is:

riscv64-unknown-linux-gnu-gcc

additionally, you are using the -march=rv32i flag, but you are using the 64 bit version of the compiler, that doesn't seem correct to me. If the target machine is a 32 bit one, then perhaps you should use the riscv32-unknown-linux-gnu-gcc

Source https://stackoverflow.com/questions/70607162

QUESTION

How to cross-compile elfutils for RISC-V?

Asked 2021-May-15 at 20:22

I want to cross-compile elfutils for a RISC-V target and I get linker errors which I don't know how to solve. I use the riscv-gnu-toolchain.

Build zlib

elfutils is build against zlib, so I need to build it first:

...

ANSWER

Answered 2021-May-15 at 20:22

I needed to add LIBS="-lz -lzstd -llzma". The full configuration command looks like this:

Source https://stackoverflow.com/questions/67548406

QUESTION

Connecting linker script with assembly file [risc-v]

Asked 2021-Jan-03 at 08:13

I'm using a RISC-V compiler, and I need to connect my linker script "variable" to assembly file instruction, for example:

In my linker script (.ld) I have this line:

...

ANSWER

Answered 2021-Jan-02 at 10:52

this is one of those "just try it" things.

Source https://stackoverflow.com/questions/65537707

QUESTION

How to prevent GCC from inserting memset during link-time optimization?

Asked 2020-Nov-03 at 02:08

While developping a bare metal firmware in C for a RV32IM target (RISC-V), I encountered a linking error when LTO is enabled:

...

ANSWER

Answered 2020-Nov-02 at 15:33

I'm not sure -fno-builtin-* does what you think it does. If you use those flags, then GCC will try to call an external function. If you don't use those flags, GCC will instead just insert inline code instead of relying on the library.

So it would appear to me you should simply not use any -fno-builtin flags.

Source https://stackoverflow.com/questions/64648300

QUESTION

RISC V linker cannot find -lgcc

Asked 2020-Oct-30 at 08:46

I'm trying to compile C code for GCC, but the linker is unable to find libgcc. I want to compile some simple tests for an RV32I core.

When I try to use the modulo operator, GCC generates a call to the soft implementation of the mod instruction.

...

ANSWER

Answered 2020-Oct-30 at 08:46

The problem comes from -L="/mnt/c/Users/camin/Documents/opt/riscv/lib/gcc/riscv64-unknown-elf/10.2.0/libgcc.a" you must only give the path to the L option. Your option should be :-L="/mnt/c/Users/camin/Documents/opt/riscv/lib/gcc/riscv64-unknown-elf/10.2.0"

the enable-multilib is working well, it only provide libraries for set of archs. However be careful to give the path of the libgcc corresponding to your arch. When you enable multilib the default one will be a 64 bit versions. Normally for rv32i, the option you need is :-L="/mnt/c/Users/camin/Documents/opt/riscv/lib/gcc/riscv64-unknown-elf/10.2.0/rv32i/ilp32".

If you don't give the good library you will probably get ABI is incompatible with that of the selected emulation error.

It would be easier to use the riscv64-unknown-elf-gcc driver to make the link because he knows all the options better. Normally it will find the necessary libraries (libgcc, libgloss ....) automatically for your arch.

Source https://stackoverflow.com/questions/64603070

QUESTION

Linker error : undefined reference to _fbss

Asked 2020-Jul-15 at 02:54

I'm sucessfully building pulp-riscv-gnu-toolchain from this this

But when I try to compile my simple source code with builded compiler, error occured.

My command is riscv32-unknown-elf-g++ -o hello hello.cpp

Error message is /home/jskim/test_toolchains_lib/gcc/riscv32-unknown-elf/7.1.1/../../../../riscv32-unknown-elf/bin/ld : cannot open linker script file riscv.ld : No such file or directory

So I try with this command riscv32-unknown-elf-g++ -o main main.cpp -T /home/jskim/test_toolchains/riscv32-unknown-elf-ld/lib/ldscripts/elf32lriscv.x

But following error occured : /home/jskim/test_toolchains/lib/gcc/riscv32-unknown-elf/7.1.1/../../../../riscv32-unknown-elf/lib/crt0.o: In function '.L0': (.text+0x10):undefined reference to '_fbss' collect2: error: ld returned 1 exit status

I'm using CentOS 7.6 and I try build this pulp-gcc with gcc 4.8.5 and 7.3.1 but both shows me same error. Please help me.

...

ANSWER

Answered 2020-Jul-15 at 02:54

I resolve the problem in this way.

Actually Here is the solution.

I'm not accurate but I think the problem is that the name is not matched. crt0, which seems to be the helper of start riscv processor has this line la a0 _fbss just basically linker can recognize this if _fbss is replaced with _edata. So i edit the assembly file which is located at pulp-riscv-gnu-toolchain/riscv-newlib/libgloss/riscv/ And rebuild the gnu toolchain. And execute your compiler with -T option like riscv32-unknown-elf-g++ -o main main.cpp -T /home/jskim/test_toolchains/riscv32-unknown-elf-ld/lib/ldscripts/elf32lriscv.x

This is the easiest solution as I think.

Source https://stackoverflow.com/questions/62905976

QUESTION

How can get g++ to use my own glibc build's headers correctly?

Asked 2020-Jul-12 at 15:37

There's a TL;DR at the end if the context is too much!

Context

I am trying to update the version of glibc a project uses to 2.23 (I know it's old, that's another issue). In order to do this, I need to swap out the libraries and use the associated interpreter.

I encountered some issues when swapping out the interpreter that looked like an ABI change, so I figured it was probably because the header files had changed somehow and started working on getting those included into the project.

At first I tried using -I to include the headers, but got an error (see below). Later I tried setting --sysroot, but this quickly felt like the wrong way of doing things since I was essentially reinventing what g++ already did with system headers. I later found another mechanism that looked more promising (see Problem section).

Could this be an XY issue? Absolutely, but either way, the problem I'm seeing seems odd to me.

Problem

I looked into whether there was a different mechanism to include headers for system libraries, such as glibc, in gcc and g++. I found the flag -isystem:

...

ANSWER

Answered 2020-Jul-12 at 15:37

In your GCC version, uses #include_next, which means that you need to make sure that the directory which contains the cmath file comes before (on the include search path) the directory with the proper math.h for the version of glibc you are building against.

You can use g++ -v to view the search path. In your case, it probably looks like this:

Source https://stackoverflow.com/questions/62795463

QUESTION

RISC-V ecall syscall calling convention on pk/Linux

Asked 2020-Jan-19 at 22:12

What is the calling convention for a syscall in a program that runs under the RISC-V pseudo-kernel (pk) or Linux?

Looking at the code generated by the riscv-gnu-toolchain the rules seem to be:

syscall number is passed in a7
syscall arguments are passed in a0 to a5
unused arguments are set to 0
return value is returned in a0

Is this it?

Is it really necessary to zero-out the unused arguments?

What about register a6? Can this be used for yet another sycall argument?

Example that calls the exit() syscall:

...

ANSWER

Answered 2020-Jan-19 at 22:12

Yes, this is basically it.

No, it isn't necessary to zero out the unused arguments. The zeroing out of unused argument when using the riscv-gnu-toolchain (with the newlib C library) is just an artifact of the newlib sycall calling code. To keep it simple, the code has a single scall (old name for ecall) wrapper with 6 syscall arguments. Thus, the exit() implementation just calls that wrapper with some additional zeroes.

As of 2020, the maximum number of syscall arguments in Linux is 6. The same goes for the pseudo-kernel. Thus, a6 is always unused.

Both Linux and pk supply the syscall number in a7. And the syscall numbers used by pk follow the Linux standard.

The syscall(2) Linux man-page also summarizes the calling conventions on different architectures, including RISC-V. It specifies a1 as possibly used to return a second return value, but this doesn't match the code in glibc and newlib.

Source https://stackoverflow.com/questions/59800430

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install riscv-gnu-toolchain

To build the Newlib cross-compiler, pick an install path. If you choose, say, /opt/riscv, then add /opt/riscv/bin to your PATH now. Then, simply run the following command:. You should now be able to use riscv64-unknown-elf-gcc and its cousins.
To build the Linux cross-compiler, pick an install path. If you choose, say, /opt/riscv, then add /opt/riscv/bin to your PATH now. Then, simply run the following command:.
To build either cross-compiler with support for both 32-bit and 64-bit, run the following command:. And then either make or make linux for the Newlib or Linux cross-compiler respectively. The multilib compiler will have the prefix riscv64-unknown-elf- or riscv64-unknown-linux-gnu-, but will be able to target both 32-bit and 64-bit systems. It will support the most common -march/-mabi options, which can be seen by using the --print-multi-lib flag on either cross-compiler.
Builds work best if installing into an empty directory. If you build a hard-float toolchain and then try to build a soft-float toolchain with the same --prefix directory, then the build scripts may get confused and exit with a linker error complaining that hard float code can’t be linked with soft float code. Removing the existing toolchain first, or using a different prefix for the second build, avoids the problem. It is OK to build one newlib and one linux toolchain with the same prefix. But you should avoid building two newlib or two linux toolchains with the same prefix. If building a linux toolchain on a MacOS system, or on a Windows system using the Linux subsystem or cygwin, you must ensure that the filesystem is case-sensitive. A build on a case-insensitive filesystem will fail when building glibc because *.os and \*.oS files will clobber each other during the build eventually resulting in confusing link errors. Centos (and RHEL) provide old GNU tools versions that may be too old to build a RISC-V toolchain. There is an alternate toolset provided that includes current versions of the GNU tools. This is the devtoolset provided as part of the Software Collection service. For more info, see the [devtoolset-7](https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/) URL. There are various versions of the devtoolset that are available, so you can also try other versions of it, but we have at least one report that devtoolset-7 works.

Support

Builds work best if installing into an empty directory. If you build a hard-float toolchain and then try to build a soft-float toolchain with the same --prefix directory, then the build scripts may get confused and exit with a linker error complaining that hard float code can’t be linked with soft float code. Removing the existing toolchain first, or using a different prefix for the second build, avoids the problem. It is OK to build one newlib and one linux toolchain with the same prefix. But you should avoid building two newlib or two linux toolchains with the same prefix. If building a linux toolchain on a MacOS system, or on a Windows system using the Linux subsystem or cygwin, you must ensure that the filesystem is case-sensitive. A build on a case-insensitive filesystem will fail when building glibc because *.os and \*.oS files will clobber each other during the build eventually resulting in confusing link errors. Centos (and RHEL) provide old GNU tools versions that may be too old to build a RISC-V toolchain. There is an alternate toolset provided that includes current versions of the GNU tools. This is the devtoolset provided as part of the Software Collection service. For more info, see the [devtoolset-7](https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/) URL. There are various versions of the devtoolset that are available, so you can also try other versions of it, but we have at least one report that devtoolset-7 works.

Find more information at: