Tier 1 Support for x86_64-plan9

[nektro]

https://9p.io/plan9/

[zigazeljko]

Targeting plan9 might be a bit trickier, since it uses a custom binary format which LLVM does not currently support (see http://man.cat-v.org/plan_9/6/a.out). From what I read, outputting that format should be doable with a custom linker script and --oformat=binary.

[nektro]

@zigazeljko is that not the same a.out kinda file that gets output by default of zig cc when you dont specify -o ?

[zigazeljko]

is that not the same a.out kinda file

No. The a.out file that gets output by default is actually in ELF (or MachO) format, and has no relation to the actual a.out format other than its name.

From Wikipedia:

"a.out" remains the default output file name for executables created by certain compilers and linkers when no output name is specified, even though the created files actually are not in the a.out format.

[g-w1]

I am working on this right now for stage2.

[Leimy]

Still being worked? Seems extremely interesting!

[g-w1]

Yes, I am just waiting for the self hosted compiler to get better at codegen. Once that happens, progress will be really quick and contributor friendly for adding plan 9 stuff to the stdlib. (The linking backend is already in place)

[zigazeljko]

@g-w1 By the way, is the plan9 syscall ABI (i.e. the stuff in os/plan9/x86_64.zig) documented anywhere?

[g-w1]

The syscalls are here http://aiju.de/plan_9/plan9-syscalls, and the abi is the same as the c one.

[zigazeljko]

The page you linked describes the API provided by libc. What I'm looking for is the underlying ABI (application binary interface) provided by the kernel -- how the values are passed to/from kernel and what instructions to use to actually perform the system call.

Taking your x86_64 implementation as an example, how did you find out that:

• syscall number is passed in rbp;
• individual arguments are passed on stack, with a zero pushed on top;
• the actual system call is performed via the syscall instruction (as opposed to int 0x40, for example);
• the result is returned in rax;
• register rcx gets clobbered.

[g-w1]

Reading generated code from the c compiler (syscall abi is the same as c fncall abi)/playing around a LOT. I don't know if there is a manpage for the abi itself.

[TheDevtop]

Hi, I'm currently using Plan 9 (9front), is there anything I can do to help Plan 9 support along?

[g-w1]

Hello! I believe the best thing would be to compile some code with it (using the standard library functions), find the bugs (there probably are some), reduce the bugs, and then fix them. If you have questions about how the linker works, you can feel free to contact me and I can talk you through it. I think I had found a bug with the relocations that you will probably find, but I didn't have the time to look into it. This tool will be your friend when doing this: https://github.com/g-w1/plan9zig/ .

[euclaise]

The handling of register clobbering from syscalls in std/os/plan9/x86_64.zig seems to be incomplete.

I've been working on partially porting musl to 9, and I found that it seems 9 makes no guarantees about saving the values of any registers on amd64 syscalls. I had to save all the relevant registers (https://git.sr.ht/~euclaise/cross9/tree/master/item/musl/p9/x86_64/sys9.s), saving only the ones that were saved here still left registers getting clobbered, although it's possible that I'm missing something.

[g-w1]

You are probably correct. I have not tested the syscalls extensively because the x86_64 backend codegen is incomplete and was the bottleneck for me (it's been a few months since I last tried, so it may have gotten better). Feel free to make a pull request fixing this if you want.

[Leimy]

Plan 9 is caller-saves per my recollection.https://9p.io/sys/doc/compiler.htmlSent from my iPhoneOn Mar 5, 2023, at 4:58 PM, g-w1 @.***> wrote: You are probably correct. I have not tested the syscalls extensively because the x86_64 backend codegen is incomplete and was the bottleneck for me (it's been a few months since I last tried, so it may have gotten better). Feel free to make a pull request fixing this if you want.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>