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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.