This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]