Idea: General syscall ABI about riscv-elf-psabi-doc HOT 11 CLOSED

Making syscalls look as much like function calls as possible is a reasonable goal. In one respect, they are quite different, though: syscalls preserve all registers, except a0. I assume we want to keep it that way.

I'm fine with t1, since syscalls could be in millicode routines that would then have to juggle the return address.

from riscv-elf-psabi-doc.

This might have been premature…

1. Linux is not fully representative in returning only one register from syscalls using the negated errno trick. The BSDs typically return two values, errno-or-return and which-was-it (the latter is usually the carry flag, but it's $a3 on MIPS). We can pretend this is a struct, but since we defined C return for small types as "exactly as passing one argument", there's a single obvious way to extend the calling convention to multiple return values.

2. L4-ish systems like to pass and return several registers unchanged (by treating them as fixed in the kernel; L4s like to treat synchronous IPC as the kernel hot path). This seems to be mostly a special case of "multiple return values", though.

3. I'm not necessarily opposed to declaring one or more registers as possibly-clobber. There's design space out there for future/alternate privileged architectures to implement ECALL without the full sscratch dance; if you want to, let's say, take a system call with interrupts automatically enabled, "sepc" has to be rerouted somewhere else, and it could be a GPR or a CSR. Not something I want to persue myself any time soon.

4. The biggest advantage of this proposal is that there's one obvious way to extend it. If someone wants 8 or 9 arguments, they can, and there's no question about how. (9 requires reading user sp, but i386 kernels already do that regularly.) Everyone on x86_64 uses argument registers a bit differently, which would be nice to avoid.

5. The biggest disadvantage is that anything that's not already broken by the calling convention changes and the ELF flag changes will no longer be able to make system calls.

from riscv-elf-psabi-doc.

Number 5 is a non-trivial concern to me, since it falls to me to do all the work.

from riscv-elf-psabi-doc.

I don't follow number 4. Either strategy supports more arguments pretty seamlessly, right?

from riscv-elf-psabi-doc.

I don't think 3 is worth considering for this privileged architecture.

from riscv-elf-psabi-doc.

The L4 approach seems roughly compatible (preserve all arguments that would not be clobbered by the syscall itself), yeah?

from riscv-elf-psabi-doc.

The errno-return style the MIPS ABI employed never made much sense to me, but treating it as an a0/a1 struct seems compatible. The trick here is the entire ABI has to know about it; presently, all glibc syscalls are treated as clobbering only a0.

from riscv-elf-psabi-doc.

The situation I was trying to avoid is: I'm porting some niche/homebrew OS to RISC-V, and I follow the Linux convention because Schelling point. Then I get to a syscall with 8 arguments. Do I (a) pass the eight argument on the stack, (b) move the syscall number somewhere else, (c) put the eight argument in a non-a-register?

Anyway, it's probably not worth changing Linux at this point. Leaving final discretion about whether to close this up to you.

from riscv-elf-psabi-doc.

@palmer-dabbelt any thoughts? I'm leaning towards "it doesn't really matter much, so let's avoid the hassle."

from riscv-elf-psabi-doc.

There are a few other nice effects of having a common ABI between function calls and syscalls, one of which is uniformity of debugging, and another of which is emulation. The two are connected - as an example, on Exherbo seccomp mode 2 is used with SECCOMP_RET_PTRACE to sandbox package building.

In addition, a common ABI between functions and syscalls makes it entirely feasible to replace an (ADDI t1, zero, NR; ECALL) sequence with (AUIPC t1, table; JALR whatever, t1, NR) or some similar sequence at relocation time in order to substitute a non-privileged syscall implementation.

This is immensely useful for anything akin to "zones", etc, and would make foreign binaries vastly easier to support - currently, the midipix project builds a custom musl in order to sub out syscalls so Linux programs can run on Windows. Using a common ABI could reduce that kind of use case to nothing more than an ELF loader patch.

from riscv-elf-psabi-doc.

This ship has already sailed. Linux does one thing and FreeBSD does another (more sensible IMO, putting the syscall number in t0 rather than wasting an argument register). Besides, this is an OS-specific concern that does not affect toolchains.

from riscv-elf-psabi-doc.