Missing sys_renameat syscall about riscv-linux

[aswaterman]

The kernel shouldn't derefence a null pointer, regardless. And that might actually fix glibc in some cases: if it is correctly returned ENOSYS, it might try a different approach.

[aswaterman]

Working on a patch

[aswaterman]

#62

[s-macke]

The patch fixes the kernel error message but a fallback to renameat2 is still not present.
According to a comment by @sorear in the patch the problem might be related to a too old glibc version.

[palmer-dabbelt]

I bumped glibc, do you mind trying with the new one?

Also, on an unrelated note, do you have RV32 Linux booting? It's not working for me...

[s-macke]

Thanks I will try it very soon.

I updated my website minutes ago. So here is the link to RV32 booting with the newest Spec: http://s-macke.github.io/jor1k/demos/riscv.html

Currently It is the safe CPU emulation, which is 10 times slower than the normal CPU emulation. Also the timer and wfi of the CPU does not work right now. I am working on it.

To run via the HTIF console my patch for riscv-pk is

diff --git a/machine/htif.h b/machine/htif.h
index fa768d8..8c7c99d 100644
--- a/machine/htif.h
+++ b/machine/htif.h
@@ -3,7 +3,7 @@

 #include <stdint.h>

-#if __riscv_xlen == 64
+#if __riscv_xlen == 32
 # define TOHOST_CMD(dev, cmd, payload) \
   (((uint64_t)(dev) << 56) | ((uint64_t)(cmd) << 48) | (uint64_t)(payload))
 #else

However I am not sure if this works for the spike emulator too, because the 64 Bit operation is splitted into two 32-Bit operations in reading and writing.

When spike implements the UART, which was introduced here,
riscv-software-src/riscv-pk@9fa7b30
it will definitely run.

Otherwise I will take a look 😄.

[aswaterman]

Using 32-bit stores doesn't work, since the HTIF can interrupt the processor between the two stores and read the wrong value.

The best way to fix RV32 is to get rid of the HTIF.

[sorear]

I think spike supports the sifive-blocks UART now, so I think the remaining users of HTIF are

1. bbl's SBI_SHUTDOWN implementation
2. the proxy kernel
3. riscv-tests

For (1), I discussed the matter with some qemu devs and they pointed me at https://www.kernel.org/doc/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt , so I can add a model of the sifive-blocks gpio driver and use that for emulator termination. What do the other two look like in a post-HTIF world?

[s-macke]

@palmer-dabbelt
No luck yet. I updated the repository riscv-gnu-toolchain to the latest riscv-next branches of binutils, gcc and glibc and tried to compile it.

After some time I get linker error while it tries to link libc.so:

/toolchain32/lib/gcc/riscv32-unknown-linux-gnu/8.0.0/../../../../riscv32-unknown-linux-gnu/bin/ld: .eh_frame_hdr refers to overlappin FDEs.
/toolchain32/lib/gcc/riscv32-unknown-linux-gnu/8.0.0/../../../../riscv32-unknown-linux-gnu/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [../Makerules:745: /build/riscv-gnu-toolchain/build/build-glibc-linux-32/libc.so] Error 1
make[3]: Leaving directory '/build/riscv-gnu-toolchain/riscv-glibc/elf'
make[2]: *** [Makefile:215: elf/subdir_lib] Error 2
make[2]: Leaving directory '/build/riscv-gnu-toolchain/riscv-glibc'
make[1]: *** [Makefile:9: all] Error 2
make[1]: Leaving directory '/build/riscv-gnu-toolchain/build/build-glibc-linux-32'
make: *** [Makefile:126: stamps/build-glibc-linux-32] Error 2

[palmer-dabbelt]

Odd. Can you try the riscv-binutils-2.28 branch? Upstream binutils master might just be unstable.

Edit: you also might have more luck with the riscv-gcc-7 branch of GCC, as that should be more stable as well.

[palmer-dabbelt]

It looks like a binutils bug. I'll look at it, but for now you can use riscv-binutils-2.28 (which is probably a good idea anyway, since that's meant to be the stable release).

riscvarchive/riscv-binutils-gdb#76

[s-macke]

@palmer-dabbelt
The toolchain compiles with the official binutils version. And I compile and run programs with it.

However he still tries to access the deprecated rename syscall.
But I think I came closer. The new glibc checks the rename behavior by checking the installed linux-headers. I forgot to update these files in risch-gnu-toolchain repository. So I guess I have to reinstall the toolchain.

[s-macke]

Good news, After I updated the linux-headers it works finally. glibc uses the new syscalls.

Bad news is, that I got the first unaligned access exception ever on the RISCV architecture. It is in the kernel:

c0251970 <rt_dst_alloc>:
........
c02519f8:       04051f23                sh      zero,94(a0)
c02519fc:       06051023                sh      zero,96(a0)
c0251a00:       06052123                sw      zero,98(a0) <- here
c0251a04:       06052323                sw      zero,102(a0)
c0251a08:       06052523                sw      zero,106(a0)
c0251a0c:       06051723                sh      zero,110(a0)

I guess, I simpliy shoudln't use riscv-next but go back and use the official checkouts in the riscv-gnu-toolchain repository.

Anyhow, the problem with sys_rename can be fixed with the new glibc and updated linux-headers and you know what to do. I close this issue.

[sorear]

@s-macke gcc@riscv-next was recently changed to treat RISC-V as an "unaligned access is legal but slow" architecture rather than a "unaligned access is forbidden" one. Does building Linux with -mstrict-align change anything?

[s-macke]

@sorear That seems to work.