GNU MCU Eclipse RISC-V Embedded GCC v7.1.1-1-20170702-0625 released

[Liviu Ionescu]

As part of the recent GNU MCU Eclipse developments, I created a new distribution of the RISC-V toolchain:

https://github.com/gnu-mcu-eclipse/riscv-none-gcc/releases/tag/v7.1.1-1-20170702-0625


This distribution is mainly identical to the SiFive 20170612 release, with the notable addition of newlib-nano support.

$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GNU MCU Eclipse RISC-V Embedded GCC, 64-bits) 7.1.1 20170509

Although the GNU ARM Eclipse project identifies the toolchain as 'riscv-none-gcc', for compatibility reasons, the executable prefix is still the unfortunate 'riscv64-unknown-elf-'; hopefully this will be sorted out some time soon.

I invite you to evaluate this new distribution and let me know your opinion.


Best Regards,

Liviu

[Tommy Murphy]

Hi Liviu

I had a look at this page:

https://github.com/gnu-mcu-eclipse/riscv-none-gcc-build

I installed a Ubuntu 16.04 64 bit Virtualbox VM and applied all updates.

I then installed the bits that your build script says it needs - docker, curl, git, automake, patch, tar, unzip, zip (some of which were already installed on a clean install)

I then followed the instructions on the above page.

But when I ran

bash ~/Downloads/riscv-none-gcc-build.git/scripts/build.sh --win32 --deb32

I got this:

Checking Docker...
/home/user/Downloads/riscv-none-gcc-build.git/scripts/helper/build-helper.sh: line 262: docker: command not found
Please install Docker (https://docs.docker.com/installation/) and rerun.

Is there something missing from the build instructions?

Thanks

Tommy

[Tommy Murphy]

Sorry - ignore that.

I had run

sudo apt-get install docker

but it looks like I (also?) need 

sudo apt-get install docker.io

When the latter is installed then the build starts running.

Apologies for the false alarm.

Regards

Tommy

[Tommy Murphy]

OK  - I spoke too soon.

The build stopped early on:

Creating the Debian 32-bits distribution...

Running "inner-build.sh" script inside "riscv-none-gcc-debian32-build" container, image "ilegeul/debian32:9-gnu-mcu-eclipse"...
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.

Can you clarify the setup/build instructions here please?

Thanks.

Regards

Tommy

[Liviu Ionescu]

> On 6 Jul 2017, at 01:17, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> When the latter is installed then the build starts running.

I suggest you start it with --without-pdf, otherwise you need to install TeX.


but you are right, the documentation is not detailed enough there, I plan to add a page like:

https://gnu-mcu-eclipse.github.io/openocd/build-procedure/

> Cannot connect to the Docker daemon

I suggest you study the docker install pages.


regards,

Liviu

[Liviu Ionescu]

> On 6 Jul 2017, at 01:14, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> I had a look at this page:
>
> https://github.com/gnu-mcu-eclipse/riscv-none-gcc-build

btw, what I announced, and expected feedback, were the binaries themselves, not the elaborated script (the scripts and the documentation are still work in progress).

did you check the binaries?


regards,

Liviu

[Tommy Murphy]

Yes - but I have projects that compile and link fine with my own build of the riscv tools but not with your build so I wanted to see if I could figure out what the build differences were.

Specifically I get this link error:

Building target: riscv-systick-blinky.elf
Invoking: GNU RISC-V Cross C Linker
riscv64-unknown-elf-gcc -march=rv32im -mabi=ilp32 -msmall-data-limit=8 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -T "C:\Microsemi\SoftConsole_v5.2.0.4\extras\workspace.examples\riscv-systick-blinky\riscv_hal\microsemi-riscv-ram.ld" -nostartfiles -Xlinker --gc-sections -Wl,-Map,"riscv-systick-blinky.map" -o "riscv-systick-blinky.elf"  ./riscv_hal/entry.o ./riscv_hal/init.o ./riscv_hal/riscv_hal.o ./riscv_hal/riscv_hal_stubs.o ./riscv_hal/syscall.o  ./hal/hal_irq.o ./hal/hw_reg_access.o  ./drivers/CoreUARTapb/core_uart_apb.o  ./drivers/CoreGPIO/core_gpio.o  ./main.o  
c:/microsemi/softconsole_v5.2.0.4/riscv-unknown-elf-gcc/bin/../lib/gcc/riscv64-unknown-elf/7.1.1/../../../../riscv64-unknown-elf/lib/rv32im/ilp32\libc.a(lib_a-fini.o): In function `.L2':
fini.c:(.text.__libc_fini_array+0x5c): undefined reference to `_fini'
collect2.exe: error: ld returned 1 exit status
make: *** [riscv-systick-blinky.elf] Error 1
makefile:48: recipe for target 'riscv-systick-blinky.elf' failed

I do not get this error with the tools that I build myself using:

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain/riscv-gcc
contrib/download_prerequisites
cd ..
./configure --prefix=... --enable-multilib
make

BTW - I read up on the docker install instructions and got docker-ce installed and the build seems to be running now.

Thanks.

[Richard Herveille]

That would be an issue with the link script. _fini_array holds the destructors to be called when main exits, if I am not mistaken. 

I've been playing with bare metal C++ and had to implement those. If you're interested I can send you my linker script file tomorrow (1am here ... 😴). 

Richard

Sent from my iPad

--
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+un...@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/e255ccc4-03e8-4924-a948-d821ac0b1563%40groups.riscv.org.

[Liviu Ionescu]

> On 6 Jul 2017, at 01:45, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> undefined reference to `_fini'

aha. this has to do with constructors/destructors.


Liviu

[Tommy Murphy]

But I'm not using C++ - just C/asm.

I'm curious as to why my build from the riscv github works but Liviu's using his setup does not.

I'm also not using newlib-nano here yet.

[Tommy Murphy]

When I compile and link with my build of the tools there is no mention of fini in the list file.

I'm also using my own startup code/crt0 equivalent.

It's late here too so I'll probably park it.

[Liviu Ionescu]

> On 6 Jul 2017, at 01:52, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> But I'm not using C++ - just C/asm.
> I'm curious as to why my build from the riscv github works but Liviu's using his setup does not.
> I'm also not using newlib-nano here yet.

unless I missed something, my distribution tries to replicate the options used by the ARM Toolchain to build newlib & newlib-nano.

it is possible that these options slightly differ from those used in your build.


I successfully built Hello World sample projects, both in C and C++, so I guess there is a small detail in the linker script.


regards,

Liviu

[Richard Herveille]

That probably should not apply to normal C code.

The stdlib contains the initialisation code for the (static) constructors, located at __init_array. And it calls the destructors located at __fini_array. Some of the code is automatically generated by GCC. 

The default linker script inside ld contains those sections. So they're automatically loaded. 

For sure something is off and I'm no expert here, just stating what I learned while playing around. 

Richard 

Sent from my iPad

--

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+un...@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/8042522f-6e13-40a3-a36b-1720fdd409e8%40groups.riscv.org.

[Tommy Murphy]

I just changed the project linker settings to use --specs=nano.specs and it links fine.

So I'm not sure what the issue is and why _fini would be an issue just because the non nano newlib is used?

[Tommy Murphy]

And my linker script should retain init and fini:

SECTIONS
{
  .text : ALIGN(0x10)
  {
    *entry.o(.text);
    . = ALIGN(0x10);
    *(.text .text.* .gnu.linkonce.t.*)
    *(.plt)
    . = ALIGN(0x10);
   
    KEEP (*crtbegin.o(.ctors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*crtend.o(.ctors))
    KEEP (*crtbegin.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*crtend.o(.dtors))
   
    *(.rodata .rodata.* .gnu.linkonce.r.*)
    *(.gcc_except_table)
    *(.eh_frame_hdr)
    *(.eh_frame)
   
    KEEP (*(.init))
    KEEP (*(.fini))


    ...

[Liviu Ionescu]

> On 6 Jul 2017, at 02:04, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> And my linker script should retain init and fini:

could you archive your project and send it to me? (hopefully without having to sign NDAs ;-)

now it is quite late, but tomorrow I'll investigate.


Liviu

[Tommy Murphy]

Thanks Liviu.

No NDAs. :-)

The exported/archived project is attached.

Let me know if you need any more info.

[Jacob Bachmeyer]

Richard Herveille wrote:
> That probably should not apply to normal C code.
> The stdlib contains the initialisation code for the (static)
> constructors, located at __init_array. And it calls the destructors
> located at __fini_array. Some of the code is automatically generated
> by GCC.
> The default linker script inside ld contains those sections. So
> they're automatically loaded.
> For sure something is off and I'm no expert here, just stating what I
> learned while playing around.

I have been working on a project unrelated to RISC-V that uses some
application-level constructors/destructors and had issues with the
destructors not being called and sometimes the constructors as well!
The simple solution turned out to be to use the gcc(1) driver when
linking shared objects instead of directly using ld(1).

Along the way, I came across documentation that suggested that _init and
_fini are obsolete and __init_array and __fini_array are the
replacements -- and I found _init and _fini entrypoints in glibc that
run through __init_array and __fini_array. If you use
__attribute__((constructor)) and such, GCC takes care of putting a
pointer to your function in the right place, (section .ctors if I
remember correctly and it hasn't changed) but the details can cause
issues if you are driving the link in some custom way. My solution was
to just use GCC to drive the link. I would not be surprised if the
standard link script puts section .ctors into __init_array and section
.dtors into __fini_array, but GCC could also link another module that
provides entries in those arrays that run through those sections.


-- Jacob

[Richard Herveille]

Correct.
I believe either .ctor, .dtor, or __init_array, __fini_array is used. Typically they are indeed stored at the same address.
RISC-V GCC uses __init_array. The libstd (libstdc++?) calls _libc_init, which calls the constructors. I skip that and directly load the constructors from my crt.S.
Btw it's only the static constructors that are stored in the __init_array.
The __fini_array is called by 'delete'.

Richard



Sent from my iPad

[Tommy Murphy]

Thanks guys but (a) I (via the GNU MCU Eclipse plugins) am already calling the GCC front end to do the link as per the link transcript that I posted earlier and (b) I'm not using C++ at all here so I'm confused as to why is trying to link stuff related to ctors/dtors at all.

[Tommy Murphy]

FWIW my win32 build eventually failed - I can't find a build log and forgot to tee the build output to a file :-( but it looks like it failed to build the win32 riscv64-unknown-elf-gcc for some reason.

cp xgcc.exe gcc-cross.exe
i686-w64-mingw32-g++ -fno-PIE -c   -Wno-format-security -Wno-char-subscripts -Wno-deprecated -Wno-array-bounds -Wno-invalid-offsetof -pipe -ffunction-sections -fdata-sections -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic-family -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/c-family -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/../include -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/../libcpp/include -I/Host/Work/riscv-none-gcc/install/win32/include -I/Host/Work/riscv-none-gcc/install/win32/include -I/Host/Work/riscv-none-gcc/install/win32/include  -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/../libdecnumber -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/../libdecnumber/dpd -I../libdecnumber -I/Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/../libbacktrace -I/Host/Work/riscv-none-gcc/install/win32/include  -o c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF c-family/.deps/cppspec.TPo /Host/Work/riscv-none-gcc/riscv-none-gcc-20170612/gcc/c-family/cppspec.c
i686-w64-mingw32-g++ -no-pie   -Wno-format-security -Wno-char-subscripts -Wno-deprecated -Wno-array-bounds -Wno-invalid-offsetof -pipe -ffunction-sections -fdata-sections -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -L/Host/Work/riscv-none-gcc/install/win32/lib -Wl,--gc-sections -Wl,--stack,12582912 -o cpp.exe gcc.o gcc-main.o ggc-none.o \
  c-family/cppspec.o  libcommon-target.a \
   libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
riscv64-unknown-elf-gcc -dumpspecs > tmp-specs
/bin/sh: 1: riscv64-unknown-elf-gcc: not found
make[1]: *** [specs] Error 127
Makefile:1994: recipe for target 'specs' failed
make[1]: Leaving directory '/Host/Work/riscv-none-gcc/build/win32/gcc-first/gcc'
make: *** [all-gcc] Error 2
Makefile:4212: recipe for target 'all-gcc' failed

[Liviu Ionescu]

> On 6 Jul 2017, at 12:56, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> it failed to build the win32 riscv64-unknown-elf-gcc for some reason.

hmmm... that's odd.

due to the specifics of building win32 executables on linux, the linux binaries must be available during the win32 build, since the script cannot use the windows executables to compile the libraries on linux.


but the script should automatically handle this, and sequence things in the right order.


regards,

Liviu

[Tommy Murphy]

I'm running a build again and redirecting the output to a file to see if it sheds any light on what goes wrong.

The final error may not be the only one I guess - as I said it looked like the win32 riscv64-unknown-elf-gcc simply had not been built while other bits of the toolchain had been.

That would obviously explain why it would not be found :-) 

But maybe the log will explain why it failed to build.

I'll post back later when I have more info.

[Liviu Ionescu]

> On 6 Jul 2017, at 14:16, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> I'm running a build again and redirecting the output to a file to see if it sheds any light on what goes wrong.

please move this thread to the project forum, and if you identify bugs in the script, to the https://github.com/gnu-mcu-eclipse/riscv-none-gcc-build/issues.

and be absolutely sure you use the latest version of the build script.


regards,

Liviu

[Tommy Murphy]

OK - will do.

I am pulling the stuff anew each time I do a build.

Once the current  build has finished (most likely failed) I'll log an issue.

Thanks.

[Tommy Murphy]

If I comment out the call to exit() in our startup/shutdown code (and in bare metal that call to exit() should be redundant) then I don't get the _fini link problem.

So I guess that there might be some difference between the GNU MCU Eclipse build of exit() and the riscv-gnu-toolchain build.

I'll try to investigate further by comparing the respective build logs and how they build the relevant file(s).

[Liviu Ionescu]

> On 6 Jul 2017, at 16:06, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> If I comment out the call to exit() in our startup/shutdown code (and in bare metal that call to exit() should be redundant) then I don't get the _fini link problem.
> So I guess that there might be some difference between the GNU MCU Eclipse build of exit() and the riscv-gnu-toolchain build.

`_fini();` is called at the end of `newlib/libc/misc/fini.c: __libc_fini_array()`

since your blinky application does not properly process static constructors/destructors and `__libc_fini_array()` is not used, the `_fini()` is not called either.

the standard newlib uses _atexit(__libc_fini_array), so __libc_fini_array is always referred, and consequently `_fini` too.

newlib-nano uses a simplified `exit()` code, so `_fini` is no longer always referred.

the SiFive examples define a functional `_init()` and an empty `_fini()` in init.c. you also have a functional `_init()` in your init.c but no `_fini()`; I suggest you also add an empty `_fini()`.



regards,

Liviu

[Tommy Murphy]

Thanks a lot Liviu - that makes sense.

[Jacob Bachmeyer]

Tommy Murphy wrote:
> Thanks guys but (a) I (via the GNU MCU Eclipse plugins) am already calling the GCC front end to do the link as per the link transcript that I posted earlier and (b) I'm not using C++ at all here so I'm confused as to why is trying to link stuff related to ctors/dtors at all.
>

GCC recognizes the "constructor" and "destructor" attributes on
functions and arranges for those functions to be run as global
constructors (before main()) and global destructors (after main()
returns or exit() is called) even in C. The GNU libc has support for
this, and (IIRC) also uses this mechanism internally.


If I am looking at the correct text, you are specifying "-nostartfiles"
which prevents GCC from adding some of the modules it normally adds to
the link. Your libc contains references to symbols defined in those
startfiles and you are not providing those symbols from your program.
Either remove "-nostartfiles" from the linker options or adapt your
program to run without them.


-- Jacob

[Richard Herveille]

There are cases where you don’t want the standard libraries. Especially in embedded systems, where the standard libraries bloat the code.

I’m playing with embedded C++, aiming for minimum code size and memory footprint. Which basically means only static methods (which requires __init_array), no dynamic memory, … I call the constructors in __init_array directly from my crt.S.

As this is embedded, main() should never exit. Thus __fini_array is not used.

Richard

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
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+un...@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/595ECE8E.8000704%40gmail.com.

[Richard Herveille]

Alternatively you can redefine __aebi_atexit() and __cxa_atexit() and call the static constructors (pointed to by __init_array) from crt.S.

That’s what I do.

/** Getting C++ to run …

 */

// for pure virtual functions

extern “C” void __cxa_pure_virtual(){

  while (true) {}

}

// this is required for static objects with custom destructors

extern “C” int __aeabi_atexit(

  void *object,

  void (*destructor)(void *),

  void *dso_handle)

{

  static_cast<void>(object);

  static_cast<void>(destructor);

  static_cast<void>(dso_handle);

  return 0;

}

void* __dso_handle = nullptr;

// ‘main’ should never exit, this should never be call

extern “C” void __cxa_atexit() {}

// the compiler always uses ‘delete’ for destructors

void operator delete (void*, unsigned int)

{

  while (true) {}

}

Richard

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
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+un...@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/1DB98879-AF66-4059-B9C7-DA69B8FEDAE5%40livius.net.

[Liviu Ionescu]

guys, thank you for your contributions, but this thread is related to the announcement of the new GNU MCU Eclipse RISC-V Embedded GCC toolchain.

the toolchain itself seems ok, including the standard newlib and the size optimised newlib-nano.

the problem reported by Tommy was identified as a missing _fini() in his application.


if you have further comments/suggestions related to the way GNU MCU Eclipse RISC-V Embedded GCC was packed and released, please share them here, but for general C/C++ comments please open a new thread.


thank you,

Liviu