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

 by   riscv C Version: 2021.08.11 License: Non-SPDX

kandi X-RAY | riscv-gnu-toolchain Summary

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

            kandi-support 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.
              OutlinedDot
              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

            kandi-Quality Quality

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

            kandi-Security 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.

            kandi-License 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.

            kandi-Reuse 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

            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:

            Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items

            Find more libraries

            Stay Updated

            Subscribe to our newsletter for trending solutions and developer bootcamps

            Agree to Sign up and Terms & Conditions

            Share this Page

            share link

            Explore Related Topics

            Consider Popular Compiler Libraries

            rust

            by rust-lang

            emscripten

            by emscripten-core

            zig

            by ziglang

            numba

            by numba

            kotlin-native

            by JetBrains

            Try Top Libraries by riscv

            riscv-isa-sim

            by riscvC

            riscv-tools

            by riscvShell

            riscv-opcodes

            by riscvPython

            riscv-openocd

            by riscvC

            riscv-pk

            by riscvC