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.