This is a work in progress. I would appreciate some feedback before working more on it. I made it compile an empty fn main() void {} for -target x86_64-plan9 -ofmt=elf, but it still needs some love going forward. Sorry if this description is ugly, but I had no way of seeing how it looks, because I pushed the PR via so-called AGit workflow (forking is currently broken on Codeberg).
WIP: bring back plan9 #36053
arusekk/plan9 into master
AGit
Okay, it worked. So this code so far has been mostly (but not only) an improved git revert so that everything compiles at least.
Now, I am a bit stuck, there are several options on how I go forward with this:
- splitting even the current changeset into smaller PRs (I will probably do it this way if I get no directional feedback, being an open source maintainer myself, I like small changes the most), or
- reworking this to be more directed and step-by-step, but keeping everything in a single massive PR that brings user-visible functionality.
Currently the reason I am stuck is that compiling
pub fn main() void {}
needs a memmove implementation, and even with a memmove it still reports unresolved relocations somehow.
I am compiling with
zig build-exe empty.zig -target x86_64-plan9 -ofmt=elf -fsingle-threaded -fcompiler-rt
My questions:
- Should I first split simple improvements out of these changes, and submit them separately? (I can see there are conflicts already; I can take it as a yes)
- Why is compiler_rt not included into the binary when running
zig build-exe -target x86_64-plan9 -ofmt=elf -fsingle-threaded -fcompiler-rt planback.zig? (mystery no. 1) - Why on earth are there relocations when running
zig build-exe -target x86_64-plan9 -ofmt=plan9 -fsingle-threaded -fcompiler-rt planback.zig? How to even debug it? Plan 9 famously does not support relocations on purpose, they should be irrelevant when doing static linking! Note that the only binary format implemented in Zig is the executable format, the object format is so much different, and architecture-specific that I do not even want to look at it. (mystery no. 2) - Do you want some CI for testing the resulting Plan 9 binaries? There is https://uglendix.dev (a Wine analogue by yours truly), which facilitates running unmodified Plan 9 binaries on Linux - in Docker or otherwise. It runs binaries compiled with Zig 0.13.0 just fine.
dafuq!? where do you even obtain a copy of Plan9 to test this on???
@bpavuk Well, since compilation is a computational task - converting source code (a sequence of bytes) into an executable (a sequence of bytes) - you can run compilation of Zig source code into a Plan9 binary by running the Zig compiler on Linux, or even on Windows if you like. Then you can inspect it using a reverse engineering tool, like Radare2 or Ghidra, or use a VM or an API translation layer to execute it. Uglendix is the latter.
Currently, there is no binary produced, even. The computation fails earlier, and I need help figuring out why.
@bpavuk wrote in #36053 (comment):
dafuq!? where do you even obtain a copy of Plan9 to test this on???
Plan9: https://plan9.io/plan9/download.html
9legacy: http://9legacy.org/download.html
9front: https://9front.org/download/
@bpavuk wrote in #36053 (comment):
@K4 this is awesome, I wish you luck.
Maybe I will help in the future, but I am not involved right now. I didn't get to a workinkg GUI with 9front when I tried and don't have actual experience with Plan9 or 9front, but I plan to in the future.
I hope that zig will get to a good state on both versions.
- lib/std/os/plan9.zig
- src/codegen.zig
- src/codegen/x86_64/Emit.zig
- src/link.zig
View command line instructions
Manual merge helper
Use this merge commit message when completing the merge manually.
Checkout
From your project repository, check out a new branch and test the changes.No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?