Building RV32E toolchain

[Gnanasekar R]

Am starting a new mail to avoid confusions in the existing ones. I tried to build the RV32E toolchain as pointed by Jim. Here is what I did,

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain

and after cloning I cd into 'riscv-gcc' and 'riscv-binutils-gdb' directories and checkout riscv-next branch,

git fetch origin

git checkout -b riscv-nex origin/riscv-next

After this I started the build as,

./configure --with-arch=rv32e --with-abi=ilp32e

Simple programs get built fine. But when I compile my project code using the built toolchain I am getting the error as shown below. The same code works fine with rv32gc toolchain and other arm toolchains. Unfortunately I cannot put the source here. Please let me know if I am not picking the right repositories

temp.c:189:1: internal compiler error: in get_variable_section, at varasm.c:1150

 }

 ^

0xe6e8e7 get_variable_section(tree_node*, bool)

../.././riscv-gcc/gcc/varasm.c:1149

0xe76360 assemble_variable(tree_node*, int, int, int)

../.././riscv-gcc/gcc/varasm.c:2279

0xe7bd99 varpool_node::assemble_decl()

../.././riscv-gcc/gcc/varpool.c:590

0xe7c9b3 varpool_node::assemble_decl()

../.././riscv-gcc/gcc/cgraph.h:1960

0xe7c9b3 symbol_table::output_variables()

../.././riscv-gcc/gcc/varpool.c:756

0x72ef4f symbol_table::compile()

../.././riscv-gcc/gcc/cgraphunit.c:2624

0x73177d symbol_table::compile()

../.././riscv-gcc/gcc/cgraphunit.c:2537

0x73177d symbol_table::finalize_compilation_unit()

../.././riscv-gcc/gcc/cgraphunit.c:2716

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See <https://gcc.gnu.org/bugs/> for instructions.

Makefile:15: recipe for target 'all' failed

make: *** [all] Error 1

[Bruce Hoult]

If the toolchain builds without errors and simple programs build to RISC-V binaries and run ok on QEMU or real hardware then there can't be much wrong with what you checked out.

There could well be some bugs that are triggered only by complex code, but without code that triggers them it's unlikely the problem can be found or fixed. A backtrace is unlikely to be enough.

If you can't supply your actual source code you should at least try to make a minimal and obfuscated version of it using https://embed.cs.utah.edu/creduce/

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CANUXKs-n08YMR%2BNpVAxcU3158fqrZv%2BOjOFxjhawwy2Mo%3D0Prw%40mail.gmail.com.

[Gnanasekar R]

Ok, thanks for the suggestion. When I have some cycles I will try with creduce.

For now I compiled the offending file separately with -c option and then linked them finally to generate the elf. With that it seems to work. 

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

[Bruce Hoult]

I just tried building an rv32e newlib toolchain using the above technique and compiled some simple programs and ran then successfully in an up to date qemu. Also objdump shows that they are using only the e register subset. So all seems reasonable so far.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

[Gnanasekar R]

Hi Bruce,

Simple programs compile fine for me too. My project has multiple files with lots of code(with many globals etc). Am not sure at this point what is the source of the problem. But I was able to get away by compiling the file separately and then link.

[Bruce Hoult]

It would be good if you can find the time to create a reduced test case that shows the problem, so the bug can be fixed.

creduce is easy to use and almost magical!

[Gnanasekar R]

sure. will try it sometime. 

[Jim Wilson]

On Mon, May 21, 2018 at 1:03 AM, Gnanasekar R <gnanase...@gmail.com> wrote:
>>>>>> temp.c:189:1: internal compiler error: in get_variable_section, at
>>>>>> varasm.c:1150
>>>>>> }
>>>>>> ^

The bug is perhaps triggered by a variable with a section attribute
attached to it.

Jim