diff options
Diffstat (limited to 'content/bootstrapGcc')
-rw-r--r-- | content/bootstrapGcc/14_g++4.6.4.md | 185 | ||||
-rw-r--r-- | content/bootstrapGcc/15_pass_to_guix.md | 96 | ||||
-rw-r--r-- | content/bootstrapGcc/16_talk_about_it.md | 34 | ||||
-rw-r--r-- | content/bootstrapGcc/guix-social.pdf | bin | 0 -> 116774 bytes |
4 files changed, 315 insertions, 0 deletions
diff --git a/content/bootstrapGcc/14_g++4.6.4.md b/content/bootstrapGcc/14_g++4.6.4.md new file mode 100644 index 0000000..9df600f --- /dev/null +++ b/content/bootstrapGcc/14_g++4.6.4.md @@ -0,0 +1,185 @@ +Title: Milestone – Bootstrapped GCC 4.6.4 for RISC-V +Date: 2024-05-17 +Category: +Tags: Bootstrapping GCC in RISC-V +Slug: bootstrapGcc14 +Lang: en +Summary: So yeah, we bootstrapped GCC 4.6.4 for RISC-V. We even have C++ + support! + +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][upstream]). +This is the only one we need to apply to GCC, as we fixed many things in +TinyCC. + +[upstream]: https://lists.nongnu.org/archive/html/tinycc-devel/2024-04/msg00028.html + +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 +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: + +``` clike +#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: + +``` something +/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[^until-it-broke]. + +[^until-it-broke]: There's something weird in this case, if I do a change like + this one below it fails: + <!-- Using a markdown fenced code block here fails --> + + <pre class="language-diff"> + <code class="language-diff"> + (native-inputs `(("gcc" ,gcc-muslboot0) + ("libc" ,musl-boot) + - ("find" ,findutils) + ,@(modify-inputs (package-native-inputs gcc-muslboot0) + + (append findutils) + (replace "make" gnu-make-muslboot) + (delete "libc") + (delete "tcc")))) + </code> + </pre> + +### 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`][commencement] project where I'm keeping track of all this. + +[commencement]: https://github.com/ekaitz-zarraga/commencement.scm/commit/9bbb1c61a87e206fb275c3040d0493beba6ae0fe + +### 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. diff --git a/content/bootstrapGcc/15_pass_to_guix.md b/content/bootstrapGcc/15_pass_to_guix.md new file mode 100644 index 0000000..69666af --- /dev/null +++ b/content/bootstrapGcc/15_pass_to_guix.md @@ -0,0 +1,96 @@ +Title: Milestone (End?) - Bootstrapping path discovered +Date: 2024-07-02 +Category: +Tags: Bootstrapping GCC in RISC-V +Slug: bootstrapGcc15 +Lang: en +Summary: A RISC-V bootstrapping path path has been discovered. Now it's time + for the distros to catch up. + + +During the latest posts I described that we managed to build GCC using our +bootstrapping chain, and also that we built a modern GCC using our bootstrapped +one, but now, some connection work has been done. It's time to report on that. + +### Bootstrapping chain discovered + +In my [`commencement.scm`][commencement] project, I started working on a +bootstrapping path following Andrius Štikonas' steps in live-bootstrap. His +work is what is driving everything for several reasons: he knows how to do it +well and Guix has a handful of peculiarities that make this way more complex +than in live-bootstrap. + +First of all, live-bootstrap uses custom Makefiles for most of the projects, +that allows it to build things without relying on the feature detection that +the configure scripts normally use. We could do the same thing on Guix but +that would mean rewriting many packages from scratch and Guix package +definitions would become way more complex than what they are right now. + +Second, live-bootstrap is launched in some kind of a chrooted environment that +is shared by all steps. This means all the packages in it share the `/` folder, +and they can easily find other programs in `/bin` and libraries and stuff in +the folders expected by the FHS. In Guix we do *not* support the FHS, and our +packages are isolated, so we need to tweak the environment variables of the +packages in order to make them find the dependencies. This sometimes requires +patching the source of some packages, and here problems appear. + +The most heavily patched package in this regard is actually GCC. It needs to be +able to work well with our environment and that's not easy to do. This makes my +job harder. + +The good news is Andrius managed to build GCC 9.5 with the bootstrapping chain +in live-bootstrap and that means we discovered a full-source bootstrapping +path for RISC-V in 64 bit that is working **right now**. + +[commencement]: https://github.com/ekaitz-zarraga/commencement.scm + +### Time to make it reach a distro + +I managed to build GCC 9.5 with C support, using our bootstrapping path, and +that's more than nothing, but we are working with Efraim Flashner (one of the +Guix maintainers) to add full support for GCC 9.5 and also Janneke is working +on top of my `commencement.scm` file to merge it with the support they already +did for x86 (and was already done when I joined this effort). + +So, the efforts to include our work in Guix are currently happening and I don't +think there's much Andrius and I can do to help in this direction. The project +is on the hands of the people that know the best. + +#### Issues + +During the project we found some small inconveniences that we could not fix, +and those must be improved but they'll take long time, as they come from some +related projects. I'd love to say I have time, energy and knowledge to fix +those, but most of them are not under my control. + +First we have the problem we detected with Gash, that produces hangs in the +very first steps of the bootstrapping process. This is really hard to fix but +Timothy Sample, the project maintainer, is working on the issue. + +Second, some of the projects we use in the bootstrapping process require some +packaging skills I lack at this very moment, but they have been bootstrapped in +live-bootstrap so this can be done. The projects are `flex` and `bison`, and +maybe a couple more, but they are out of the scope of the project so I just +used the non-bootstrapped ones and left them as *to-do*s in the +`commencement.scm` file[^issue]. + +[^issue]: I also left those because we don't build them from source in Guix + yet. See <https://issues.guix.gnu.org/52311> + + +### What now, then? + +I think what to do next is pretty obvious now: handover to Guix. + +I'll open an issue in Guix in the following days where we'll discuss the +inclusion of this bootstrapping path in Guix in the following months, as the +other related issues are fixed and more steps are included in the chain. + +This handover process will take time because the bootstrapping path doesn't end +in a modern GCC, but in a *proper* GCC, GLibC, and some other packages that are +required for almost everything. Our discovery is enough to continue further, +but we didn't do that as our goal was to provide the RISC-V support in the +places were it wasn't ready. We have already shown that we did that. **Now I +guess it's time for the distros to catch up**. + +Of course, with our help. As always. diff --git a/content/bootstrapGcc/16_talk_about_it.md b/content/bootstrapGcc/16_talk_about_it.md new file mode 100644 index 0000000..7a93e9c --- /dev/null +++ b/content/bootstrapGcc/16_talk_about_it.md @@ -0,0 +1,34 @@ +Title: [Talk] Full Source Bootstrapping RISC-V on Guix +Date: 2024-09-19 +Category: +Tags: Bootstrapping GCC in RISC-V +Slug: bootstrapGcc16 +Lang: en +Summary: People from **Guix London** gave me the chance to describe this + process. + +Guix London[^london] gave me the chance to talk about this whole bootstrapping +process and I delivered. + +- [Slides]({attach}/bootstrapGcc/guix-social.pdf) +- [Video recording (youtube)](https://www.youtube.com/watch?v=Cj7DyiRqWBk) + +In the talk I explain what RISC-V is, how is the Linux support right now, and +which changes we added to `(gnu packages commencement)` in Guix. + +Later, I share my thoughts about some social/emotional part, as I always do, in +this case focusing the attention in *leadership* and how our *sensei* **Ludovic +Courtès** is a great example of what I want to be as a free software developer +that was given some responsibility. + +Then there are some questions, really good questions (thanks for that!), and we +discuss a little bit about **NlNet** and how the grants work. You might be +interested on that if you want to propose a project. + +Just that, I hope you like the talk. + +Fill my inbox with your questions, specially if they are interesting. + + +[^london]: Thanks to the people from Guix London: **Steve**, **Fabio** and + **Arun**. diff --git a/content/bootstrapGcc/guix-social.pdf b/content/bootstrapGcc/guix-social.pdf Binary files differnew file mode 100644 index 0000000..09a1525 --- /dev/null +++ b/content/bootstrapGcc/guix-social.pdf |