* Implement syscall readlinkat
* Implement syscall readv by read syscalls
Since pk lacks kernel-space dynamic memory management, we implement readv with
normal read syscalls rather than forwarding it to spike
* Implement syscall readlinkat
* Implement syscall readv by read syscalls
Since pk lacks kernel-space dynamic memory management, we implement readv with
normal read syscalls rather than forwarding it to spike
We previously kernel-panicked because that made it more obvious when a
syscall implementation was missing. These days, it's more common that
the C library will do something sensible in response to returning -ENOSYS.
Favor that approach to avoid frustrating users.
`SYS_getcwd` is different from `getcwd` in that the return value is < 0
on failure otherwise it is the length of the string. The proxy kernel
was treating 0 as success and all other values as error. As a result,
we would never return a valid value for `getcwd`.
The following program now executes properly with the Proxy Kernel:
```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <linux/limits.h>
int main(int argc, char **argv) {
unsigned char buffer[PATH_MAX + 1] = {0};
if (getcwd(buffer, PATH_MAX))
printf("cwd: %s\n", buffer);
return EXIT_SUCCESS;
}
```
Previously, the pk would always run from virtual address MEM_START.
Instead, remap it into the negative virtual addresses, allowing user
processes to expand beyond MEM_START.
This attempt at rounding leads to wrong results, for example:
314689951 cycles
314690101 instructions
0.90 CPI
With my change results in:
314689951 cycles
314690101 instructions
0.99 CPI
I think this was supposed to be part of rounding behaviour but it doesn't work if only the final digit does it and there is no carry...
Instead I changed it to truncate after the second digit
This is technically possible by running an RV32 supervisor on an
RV64 machine, but the M-mode and S-mode code would need to be
compiled and linked separately.