This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RISC-V glibc port, v5
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: rjones at redhat dot com
- Cc: joseph at codesourcery dot com, libc-alpha at sourceware dot org, Andrew Waterman <andrew at sifive dot com>, Darius Rad <darius at bluespec dot com>, dj at redhat dot com, patches at groups dot riscv dot org
- Date: Thu, 25 Jan 2018 18:58:55 -0800 (PST)
- Subject: Re: RISC-V glibc port, v5
- Authentication-results: sourceware.org; auth=none
On Thu, 25 Jan 2018 11:59:33 PST (-0800), rjones@redhat.com wrote:
On Thu, Jan 25, 2018 at 05:58:15PM +0000, Joseph Myers wrote:
On Wed, 24 Jan 2018, Palmer Dabbelt wrote:
> I believe we've taken into account all the feedback, and are now below 20 test
Still missing an ldd_rewrite_script setting as mentioned as needed for
multi-ABI support in
<https://sourceware.org/ml/libc-alpha/2018-01/msg00008.html> and
<https://sourceware.org/ml/libc-alpha/2018-01/msg00521.html>.
The most important thing to figure out at this point - and then stick to
(changing your mind after the start of the freeze is not a good way to get
a port into 2.27) - is the choice of exactly what architecture and ABI
combinations are supported by the port, as that determines what changes
are needed to have an internally consistent port without lots of
untestable code for unsupported combinations, and a significant proportion
of issues from the patch reviews of multiple versions of the RISC-V port
have been inconsistencies regarding what is supposed to be supported
(especially when the choice has changed between versions of the port,
without the changes being carried out consistently through the whole patch
series).
I don't speak for Palmer nor SiFive, but from my point of view the
urgency to get this in glibc 2.27 is so we can get a stable ABI, which
we can then use to sanely port Fedora & Debian over to RISC-V.
That's the urgency on my end as well -- if we don't get distros started porting
now, then I'm going to have to add porting a distro to my already crushing
workload.
The specific hardware we are targetting initially is the 64 bit SiFive
Freedom U500 [I don't know what the chip will be called in the end -- E500?]
which is RV64GC.
The chip is called the "FU540-C000", which follows the same naming
scheme as our other chip (FE310-G000):
* Freedom means it's a chip, as opposed to just a soft IP.
* U (unleashed) means it's a unix-class processor, as opposed to E (everywhere)
means it's an embedded processor. The difference at the ISA level is
essentially just virtual memory, but the microarchitecture on the U chips
tends to be a bit beefier as well.
* 5 means it's RV64I, while 3 means it's RV32I.
* 4 means it's IMAFDC, while 1 means it's IMAC.
* I'm not sure what the 0 means :)
* G and C indicate the process used to fabricate the chip: G is TSMC's 180nm
Gplus, while C is TSMC's 28nm HPC.
* 000 also doesn't have much meaning yet, but I assume it's another
tapeout-specific parameter.
I believe therefore the only stable ABI we care about is rv64gc/lp64d.
Anything else can be unstable/omitted/whatever.
I agree. I'd like to get all the rv64 targets in just for sanity. Darius just
got the test results back for rv64imac/lp64 and they look good, so we should be
all set.