Ekaitz's tech blog:
I make stuff at ElenQ Technology and I talk about it

In latest posts we talked about many things: problems, our changes to other projects and other things. Now it’s time to actually talk about something we actually did.

But first, we fixed more extra things… This is a never ending story.

The things we need to deal with

We have been trying to build GCC 4.6.4 with the backported RISC-V support using TinyCC. We already did a GCC 4.6.4 that worked but we only tested it building with a modern GCC. Building with a TinyCC with an incomplete backend that we had to improve ourselves is not that obvious as it would be with the very well established architecture like i386.

We could build a minimal GCC, from TinyCC and Musl, but it didn’t work. Me and my colleague Andrius Štikonas detected and patched around a problem that we still don’t know where it is coming from (we reported upstream). This is the only one we need to apply to GCC, as we fixed many things in TinyCC.

This simple patch was enough to build the whole GCC. Can you spot the difference?

We find this kind of problems making small reproducers that we tried to tweak, and happened to work if we split things.

diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index d05f8149170..d4ef8de4813 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -300,6 +300,7 @@ static inline void *
 ssa_operand_alloc (unsigned size)
 {
   char *ptr;
+  int x;

   gcc_assert (size == sizeof (struct use_optype_d)
              || size == sizeof (struct def_optype_d));
@@ -334,8 +335,8 @@ ssa_operand_alloc (unsigned size)
       gimple_ssa_operands (cfun)->operand_memory_index = 0;
     }

-  ptr = &(gimple_ssa_operands (cfun)->operand_memory
-         ->mem[gimple_ssa_operands (cfun)->operand_memory_index]);
+  x = gimple_ssa_operands (cfun)->operand_memory_index;
+  ptr = &(gimple_ssa_operands (cfun)->operand_memory->mem[x]);
   gimple_ssa_operands (cfun)->operand_memory_index += size;
   return ptr;
 }

We need to rebuild with Musl

Once that very first GCC compiles, it’s necessary to rebuild Musl with that GCC, and use the new GCC+Musl combination to rebuild GCC, now adding the C++ support we missed first time.

This gives us several things: a more stable GCC and a better Musl, that is compatible with GCC.

If we don’t do that, and we don’t rebuild Musl, we see errors when building the second GCC, the genmddeps program, which is created and run during build process of GCC just fails.

Also, we have to --disable-bootstrap, so rebuilding it is like doing the GCC’s bootstrap ourselves.

Backport Musl support to GCC 4.6.4

Next thing, remember from previous posts why we had to use Musl for our process. First, because it’s a fully-featured C standard library; second, because it’s simple and easy to build and, lastly, because we can’t use GlibC: the newest version we can build doesn’t support RISC-V.

The main problem we have with GCC 4.6.4 since we started with all this journey is that 4.6.4 was written before our architecture, RISC-V, was invented, and this also happened with Musl.

Andrius detected some missing declarations during the compilation process of the libstdc++, which happened because GCC was trying to use some GlibC specific functions for the build we didn’t have, as we were using Musl instead.

Turns out GCC needs extra configuration for Musl, that was added after our version was released, so I backported all that (not much) to GCC 4.6.4. Maybe I missed something, but now we can build GCC 4.6.4 with C++ support, using Musl, for RISC-V!

But it doesn’t work!

Right after building it, we tried to use it on a simple program:

#include<iostream>

int main (int argc, char* argv[]){
    std::cout << "Hello World" << std::endl;
    return 10;
}

But this returns a huge set of errors looking like:

/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(c++locale.o): In function `.L0 ':
(.text._ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi+0x3a): undefined reference to `operator new[](unsigned long)'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(c++locale.o): In function `.L15':
(.text._ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi+0x172): undefined reference to `operator delete[](void*)'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(c++locale.o): In function `.L11':
(.text._ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi+0x190): undefined reference to `__cxa_call_unexpected'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(c++locale.o): In function `.L0 ':
(.text._ZSt14__convert_to_vIdEvPKcRT_RSt12_Ios_IostateRKPi+0x3a): undefined reference to `operator new[](unsigned long)'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(c++locale.o): In function `.L39':
(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0x1b4): undefined reference to `__cxa_call_unexpected'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L23':
(.text._ZNSi6ignoreEl+0x21c): undefined reference to `__cxa_end_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L24':
(.text._ZNSi6ignoreEl+0x22e): undefined reference to `__cxa_end_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.LEHB2':
(.text._ZNSi6ignoreEl+0x24c): undefined reference to `__cxa_begin_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L31':
(.text._ZNSi6ignoreEl+0x272): undefined reference to `__cxa_rethrow'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.LEHE2':
(.text._ZNSi6ignoreEl+0x27c): undefined reference to `__cxa_begin_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L30':
(.text._ZNSi6ignoreEl+0x29c): undefined reference to `__cxa_end_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L51':
(.text._ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl+0x22c): undefined reference to `__cxa_end_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L52':
(.text._ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl+0x23e): undefined reference to `__cxa_end_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.LEHB9':
(.text._ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl+0x25c): undefined reference to `__cxa_begin_catch'
/gnu/store/f3chm93gvrina083lqp36qpf2w4fc3f1-profile/lib/libstdc++.a(compatibility.o): In function `.L59':
(.text._ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl+0x282): undefined reference to `__cxa_rethrow'
collect2: ld returned 1 exit status

Again, Andrius detected there was a line in the huge logs we have that said we were missing the find command. So we added it, and worked¹.

The thing built, and worked!

So we managed to make it build and run, improving TinyCC in the process. Now TinyCC can build Musl and GCC 4.6.4 (with a very small patch), and that GCC is able to build itself, adding C++ support. And of course, the thing works!

You can try if this thing worked, and see how, in the commencement.scm project where I’m keeping track of all this.

Next

So yeah, success but this didn’t end. Now we need to use that GCC to build GCC 7.5, and compile the world with it.

Cross fingers.