Re: Introduction + interest in a riscv64 port of GNU Mach/Hurd
Hakan Candar <[email protected]>
| Newsgroups | gmane.os.hurd.bugs |
|---|---|
| Message-ID | <4NwuD1f_bOGQqQq0MHe0RR2s-FXFmQwb-wiz4BGD11WmPuBYkoi-Xz71u9o3P4cXLb6h3ThaZG1fHjQn08omseSAarMI7V4_y0pmJvzPF3g=@candar.tr> |
Hello Sergey, > I'm happy to discuss (what I remember of) the AArch64 port design > questions and decisions we made. Incidentally, I'm also looking into > RISC-V (just learning basic things about it), so it would be > interesting to watch, and potentially participate, in a Mach porting > effort. That would be lovely, I am glad you are considering to possibly participate in the RISC-V porting effort. After all, it is most probably you who has the most experience in porting Mach into an architecture that is not x86. No concrete progress has been made yet since the stub build, so you did not miss anything at all. You'll probably have a faster time iterating over the stub port than I would, as my knowledge of Mach internals and porting comes nowhere as close as yours. > And a small rant of what I've seen this far: the 'la' instruction (and > the PIC/non-PIC terminology) makes no sense, what were they thinking? > Fortunately it's only a pseudo-instruction and we can always use 'lga' > and 'lla', or the actual instructions behind those, and ignore the > existence of 'la'. That's funny, I actually never used 'la' myself. Does GCC/Clang even use that at all? I thought everyone does auipc+addi, as that's what the compilers output in general. When I'm writing hand-written assembly, I try to match how the compiler does these, as using the assembler directives can generate relocations that do not work on non-PIC code. Explicitly writing the auipc+addi sequence also is clearer imo and clearly distinguishes whether something is a GOT or a direct load. > The 'gp' thing (and the linker relaxation around > it) only seem useful for firmwares and small kernels, and perhaps it'd > actually be useful for gnumach, but it does seem fairly useless for > userland (considering libraries), and there could be better ways to > make use of the register. I heard that some ABIs (Haiku, Android, > Fuschia?) are _not_ using x3 as gp, and there's official ELF support > for this (Tag_RISCV_x3_reg_usage), what would you all think about > potentially doing the same for riscv64-gnu userland? The current toolchains that target GNU/Hurd (Clang and GCC) use whatever ABI GNU/Linux uses, so that'd be the gp-as-reserved-register case, I think? If we were to change that, we need to send patches to GCC and LLVM, changing the default Mach ABI. I think we should keep the current behaviour as it'd be consistent with the GNU/Linux ABI, but that is just my opinion. Hakan