Open lenary opened 4 years ago
Am I right in thinking that 32-bit glibc patches still aren't upstreamed? If so, it seems logical we'd want to have one toolchain for real-world use, using upstream glibc etc. Then another, less supported toolchain for our testing use cases that hopefully we can retire if the 32-bit glibc stuff ever moves forwards.
Yarp, I created this issue to document that (because I keep forgetting).
So, sounds like two toolchains! Fun!
I think the glibc-2.30
riscv64 toolchain will not be multilib, it will be rv64gc/lp64d
. I'll look at adding a config for that tomorrow.
glibc-2.30 upstream changed the names of some fields thread context structs for RISC-V. The sanitizers use the new names, and will not compile against the old names.
glibc-2.30 only has support for 64-bit linux. You cannot build it with 32-bit linux (it errors).
The 32-bit
glibc
patches seem to have been abandoned, riscv/riscv-glibc only contains patches for version 2.29.We would like to build a multilib toolchain for
riscv64-unknown-linux-gnu
that includes support for both 32- and 64-bit linux, that we can use as a testing environment.We should be testing the sanitizers and rest of compiler-rt.
At the moment, the feeling is that we'll build a
riscv64-unknown-linux-gnu
toolchain which does not include support for multilibs, but that doesn't really solve any testing issues.Do we want two riscv-unknown-linux-gnu toolchains? One with glibc-2.30 and one with multilib support?