This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 00/10] RISC-V glibc port for the 32-bit
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: zongbox at gmail dot com, joseph at codesourcery dot com, Arnd Bergmann <arnd at arndb dot de>, Alistair Francis <Alistair dot Francis at wdc dot com>
- Cc: Darius Rad <darius at bluespec dot com>, Andrew Waterman <andrew at sifive dot com>, dj at redhat dot com, libc-alpha at sourceware dot org, zong at andestech dot com
- Date: Sat, 08 Dec 2018 12:08:58 -0800 (PST)
- Subject: Re: [PATCH v4 00/10] RISC-V glibc port for the 32-bit
On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:
Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道：
Could you confirm the ABI entries that would be added to
<https://sourceware.org/glibc/wiki/ABIList>?
We would need to add the ABI entries as following:
32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1
32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1
Could you confirm the minimum upstream kernel version that supports 32-bit
RISC-V with the syscall ABI that will remain supported long-term? Is it
4.15, or a later version? (If a later version, arch_minimum_kernel needs
to be set accordingly.)
I had checked with Palmer, and Palmer would confirm this here.
Sorry for the confusion. A few of us sat down at the toolchain microconference
at Plumbers and we decided it would be best to wait until the 32-bit Linux port
is ready to support a 64-bit time_t ABI. This isn't ready yet and won't be
ready in time for the glibc freeze.
The options considered were to:
* Submit this port, which matches the current Linux ABI. This has been stable
since 4.15.
* Try to push all the 64-bit time_t stuff into the next releases, so Linux
4.21 (which is not out yet).
* Wait until after the next glibc release and then submit the port, ideally
also against Linux 4.21.
We all decided to wait, as if we submit this now we'll end up with a RV32I
glibc port that's 32-bit time_t. We'd then have to go do another 64-bit time_t
port along with everyone else, thus making this original port obsolete -- we'd
have to support the 32-bit time_t port forever, which seems like a headache.
The plan we came up with was to instead:
* Review this port as if it was to be submitted, so we can sort out the issues.
* Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc
release, that we can then use the bring up the port of at least one distro.
I know OpenEmbedded is coming up for RV32I, which would give me a lot more
confidence we have an actual working port.
* Submit the port after the upcoming release in February.
* Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,
which should be possible at least for all core kernel functionality.
I know Zong was at Plumbers, maybe you missed the tool chain thing?
Is this OK with everyone?