Problems with the x86 port being bitrotten #3
Comments
|
Ideally, we'd upgrade the toolchain to something shiny, and modern, and fix everything, in a big bang, but given the age of the code, it might be best if we gradually work through generations of toolchain, to see how things break - although that would delay implementing more interesting stuff, and take a very long time. We can still take that approach, but one way to extract ourselves from having to maintain ancient Docker images, and VMs would be to implement the Linux ABI itself (see issue #7), to a point where we can just unpack DEBs/RPMs, and run the toolchain on Orion, without having to rebuild it, and implement perfect source/feature compatibility with everything, immediately. Since the goal is to eventually become self-hosting, and make a usable system, this could also help with fleshing out a design for things like memory management, and file system APIs, by giving a baseline feature set to work towards. |
|
The changes to port over the NICTA enhancements (in #9) break things, even more, it seems. |
|
Presently, the master branch (which doesn't include all of the NICTA changes) gets fairly far, with the standard Ubuntu 8.3.0 compiler: |
|
Added some build logs, to the master branch, using the following x86 compilers: |
|
The NICTA_Pistachio_Mainline_FCL branch is in horrible shape, right now: |
With the preprocessor patch, in 1a1ab9b, things get a little further, but it's not a reliable fix. |
If we move the debug.h, from include/arch/ia32, we get: |
|
Moved over the remaining ia32 files, into their own directory, for comparison... |
|
64-bit support is different, again: |
|
Current status is - much of the userland builds OK for x86-64, at the moment, but building the kernel on the latest master bails for x86-32, with: |
|
The 32-bit port currently does this: Seems like a regression. |
|
64-bit one: |
|
Unsure if it's a happy accident, or a glitch, but with GCC-6, on x86-64, I could seemingly build most of userland: |
|
With liblinux, but no malloc: |
|
As a side-effect of other work, quite a lot of the x86-64 stuff seems to build, at the moment, and as part of #22, I moved over some of the NICTA x86 stuff, for later examination. |
|
Some problem, right now, with the x86-32 build: |
|
After moving the NICTA version of traceids.h, we get to: |
|
State of x86-64 build: |
|
With a little force, I was able to build the userland, for x86-64, mostly. |
|
|
Fixed the |
|
Since enabling support for building on FreeBSD/x86-64, and fixing more |
|
On Linux: |
|
Quietly, on a fork (https://github.com/nullpo-head/pistachio) of the https://github.com/l4ka/pistachio repository, there were some changes, towards getting a working x86-64 kernel building/booting, under Linux, so I've ported them across to Orion, and Enryo, although they're mostly-untested, as of writing. They mostly change the Makefiles, KickStart ELF loader, KIP headers, fix some definitions, and define some new data structures, and tweak things for GCC 7/Ubuntu 18.04, but are fairly non-evasive, and don't seem to break things any more, than they already are. |
|
The API of |
|
Not actively-maintained as a project, but I merged all of the stray forks that I could find, into https://github.com/vmlemon/pistachio, and it seems to successfully-build an x86-64 kernel (curiously, the EFI option also lights up, somehow), so it might be worth seeing the headers, and some other files, to get things working, here. |
|
As an experiment, I looked into transplanting some of the Enryo headers, to Orion, on the |
|
Out of curiosity, I tried to build that codebase, on POWER8/Fedora, and it bails out, with vmlemon/pistachio#5. Seems that we've got a lot of work ahead, to make things whole... |
|
As an experiment, I'm working on backporting some of the Orion fixes (without pulling in the NICTA stuff, wholesale), and various community patches, as well as the Orion userland, to Enryo, to create an interim Orion/E product, in the old repository, at https://github.com/vmlemon/pistachio. |
|
The status of Orion/E, is that the kernel, and userland all build, for x86-64, but not for POWER. Still trying to diagnose why, but it appears that even without the NICTA enhancements, a lot was always broken, in what we inherited, from upstream Pistachio. |
|
Pulled in the branches from the other repository, to play with, later. |
|
Merged the We'll work backwards, and see what NICTA changes are useful, for improving the architecture support, without dragnetting everything in, like before... |
|
Everything is now in In time, I'll start looking at migrating the NICTA enhancements, and platform ports, appropriately. We also still need to fix the POWER port, but having fixed-up x68 gives us a baseline to work from, and it provides the most complete genealogy of Pistachio-based projects, publicly-available, so far. As mentioned, both the x86 Orion userland, and Enryo kernel build, without issues, on Ubuntu, and the kernel starts building, on FreeBSD, with some |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In predecessor projects (e.g. Enryo, and i9), we used older versions of the GCC toolchain/compilers, and GRUB, that made certain, fragile assumptions regarding data structure alignments, linkbase addresses, stack-smashing protection, and MultiBoot structures, that are gradually becoming false, as newer versions eclipse them.
For instance, upstream Pistachio have known about l4ka/pistachio#13, for a long time, but sadly, no fix is forthcoming. :(
The x86 code also uses a lot of AT&T Assembly, that CLang/LLVM refuses to compile, and assemble, so we end up being locked-in to a single compiler, and version.
Even though GCC is Open Source, and portable, there's no guarantee that older versions will always be buildable, with newer ones; and, although we could ship a VM/Docker image, with an old OS, and toolchain, we're responsible for its security, providing hosting of such huge files, and maintaining GPL compliance. That would also limit us to a single CPU architecture, which is a pain, since we also want to run on POWER/PPC/Cell, and probably also ARM/SPARC/RISC-V, in the future.
Annoyingly, over time, a lot of resources have just disappeared from the Web (especially the NICTA, and OKL4 stuff, and the L4Ka site, at KIT has a lot of broken links, now), so it's becoming harder to figure out the care, and feeding of such old code, in order to make a smooth transition to modern alternatives, which makes it imperative on Orion, to maintain copies of them, for future reference.
The text was updated successfully, but these errors were encountered: