Make CloudABI work on i386.

[ed]

Summary

Copy over amd64's cloudabi64_sysvec.c into i386 and tailor it to work.
Again, we use a system call convention similar to FreeBSD, except that
there is no support for indirect system calls (%eax == 0).

Where i386 differs from amd64 is that we have to store thread/process
entry arguments on the stack instead of using registers. We also have to
put an extra pointer on the stack for TLS (for GSBASE). Place that
pointer in the empty slot that is normally used to hold return
addresses. That seems to keep the code simple.

Test Plan

All of CloudABI's C library's ~900 unit tests pass.

[ed]

Remove stale comment.

[kib]

This looks fine in the sense that it does not affect other parts of kernel and seemingly does not introduce exploitable flaws into the syscall calling sequence.

OTOH, I do not quite understand the handling of user-space TCB. The TCB structure size (3 words) and meaning of the first and second words (self-pointer and dtv pointer) are fixed by ABI, from what I understand. In particular, the first and the second words are directly accessed by the compiler-generated code, it seems. Am I wrong ? If not, you cannot really reuse it for the arbitrary data. You might do so for the third word.

[ed]

In D7590#157790, @kib wrote:

This looks fine in the sense that it does not affect other parts of kernel and seemingly does not introduce exploitable flaws into the syscall calling sequence.

Thanks!

OTOH, I do not quite understand the handling of user-space TCB. The TCB structure size (3 words) and meaning of the first and second words (self-pointer and dtv pointer) are fixed by ABI, from what I understand. In particular, the first and the second words are directly accessed by the compiler-generated code, it seems. Am I wrong ? If not, you cannot really reuse it for the arbitrary data. You might do so for the third word.

I took some time to read Ulrich Drepper's spec on TLS and I think what CloudABI does here is pretty safe. In section 3.4.2, it says that compiler generated code should never access things like the dtv directly. It is already effectively opaque. I also haven't seen any code part of at least Clang that tries to access it. This is why I decided it would make more sense to give the TCB its existing purpose: to allow the environment (e.g., an emulator) to keep track of per-thread state.