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: Andrew Waterman <andrew at sifive dot com>
- To: Palmer Dabbelt <palmer at dabbelt dot com>
- Cc: Zong Li <zongbox at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, Arnd Bergmann <arnd at arndb dot de>, Alistair dot Francis at wdc dot com, Darius Rad <darius at bluespec dot com>, DJ Delorie <dj at redhat dot com>, libc-alpha at sourceware dot org, Zong Li <zong at andestech dot com>
- Date: Sat, 8 Dec 2018 13:33:16 -0800
- Subject: Re: [PATCH v4 00/10] RISC-V glibc port for the 32-bit
- References: <CA+ZOyagmb6hj_j6DC6Rb5xyb2JZn7HDLSYszdR1V54dtLry3GQ@mail.gmail.com> <mhng-dbfd3137-43d5-49b5-bfcf-a01e4962506c@palmer-si-x1c4>
On Sat, Dec 8, 2018 at 12:09 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> 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?
I support this plan.