[PATCH v4 00/10] RISC-V glibc port for the 32-bit

Palmer Dabbelt palmer@dabbelt.com
Sat Dec 8 21:25:00 GMT 2018


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?



More information about the Libc-alpha mailing list