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: Alistair Francis <Alistair dot Francis at wdc dot com>
- To: "palmer at dabbelt dot com" <palmer at dabbelt dot com>, "arnd at arndb dot de" <arnd at arndb dot de>, "zongbox at gmail dot com" <zongbox at gmail dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Cc: "darius at bluespec dot com" <darius at bluespec dot com>, "andrew at sifive dot com" <andrew at sifive dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "dj at redhat dot com" <dj at redhat dot com>, "zong at andestech dot com" <zong at andestech dot com>
- Date: Mon, 10 Dec 2018 17:17:55 +0000
- Subject: Re: [PATCH v4 00/10] RISC-V glibc port for the 32-bit
- References: <mhng-dbfd3137-43d5-49b5-bfcf-a01e4962506c@palmer-si-x1c4>
- Wdcipoutbound: EOP-TRUE
On Sat, 2018-12-08 at 12:08 -0800, Palmer Dabbelt 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.
Yep, OE has a full RV32I port buildling and booting on QEMU.
If you have a branch you would like us to help test let me know and I
can update meta-riscv.
Alistair
> * 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?