This is the mail archive of the
mailing list for the glibc project.
Re: RISC-V glibc port v2
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: joseph at codesourcery dot com
- Cc: 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
- Date: Wed, 20 Dec 2017 12:25:15 -0800 (PST)
- Subject: Re: RISC-V glibc port v2
- Authentication-results: sourceware.org; auth=none
On Wed, 20 Dec 2017 08:04:50 PST (-0800), firstname.lastname@example.org wrote:
On Tue, 19 Dec 2017, Palmer Dabbelt wrote:
We're planning on supporting 6 glibc configurations on RISC-V, all of which we
internally run regression tests on:
* -march=rv64imafdc -mabi=lp64d -- what we expect to be the most used
* -march=rv64imac -mabi=lp64 -- soft floating point
* -march=rv64imafdc -mabi=lp64 -- soft float ABI, but allowed to use
hardware floating point instruction. This
is like softfp in ARM land.
* -march=rv32imafdc -mabi=ilp32d -- rv32i is a 32-bit ISA
* -march=rv32imac -mabi=ilp32
* -march=rv32imafdc -mabi=ilp32
But you also define dynamic linker names for the "f" ABI variants (lp64f,
ilp32f), so, as per my previous comments, those should be built by
build-many-glibcs.py and included in at least some testing.
Oh, sorry -- lp64f and ilp32f aren't going to be supported in glibc/Linux, just
to reduce the number of ABI combinations. I'll remove them from the v3.
* Our test suite results are very bad, but I believe this is because we're
running on QEMU's user-mode emulation which is known to be both buggy and
incomplete. I'm bringing up userspace again to produce a more reasonable
test suite run, which will hopefully have a much cleaner run.
Full execution test results - meaning on QEMU system-mode emulation or
hardware, not user-mode emulation - are definitely needed to judge whether
a port is ready for inclusion (I've suggested < 20 architecture-specific
FAILs as indicative of a state comparable to other reasonably
OK -- the only reason I've been running user-mode emulation is because that's
how our test scripts are setup. I'm working getting enough of a userspace
together to run the test suite natively now. We've had this before, there's
just nothing based on the 4.15 RC headers and I want to make sure everything
absolutely lines up.
Note that there is no need for the glibc you are testing to be
ABI-compatible with any glibc in your userspace's root filesystem, so you
don't need to rebuild userspace (if e.g. it's using older glibc with
different symbol versions) to test current glibc. It *does* need to be
able to find libgcc_s and libstdc++ shared libraries at runtime, but you
can copy those into the glibc build directory before running tests.
* I've only added one configuration to build-many-glibcs.py, which I haven't
actually run yet. I'll rectify this, but I wanted to at least get something
out so everyone was on the same page here -- the commit is more of a TODO
than an actual commit.
There should be at least one per ABI in there. Additional variants for an
ABI (e.g. varying whether hard or soft float is used with a soft-float
ABI) are optional, depending on whether you think they provide useful
additional coverage of significantly different code in glibc getting
built. Such variants should typically only need listing in extra_glibcs
so they get built in a "glibcs" build but not a "compilers" build.
Depending on the multilib configurations used by GCC you may or may not
need as many GCC builds as different ABIs (e.g. MIPS has 24 ABIs, so 24
glibc builds in build-many-glibcs.py, but only 8 separate GCC builds, each
with multilibs for 3 ABIs).
We currently support all the glibc targets in a single GCC build and we hope to
keep it that way, so hopefully this says a bit easier for us. Thanks, though
-- part of the reason I only put one entry in was because I wasn't sure what to
It's important to make sure that the build is completely clean for the GCC
/ glibc variants you add, including no failures of compilation tests.
(That is, clean given that you substitute a checkout of Linus's git tree
for the default release version of Linux - obviously the builds can't be
clean from the bots until the Linux 4.15 release comes out.)
Makes sense. I'll be sure this is the case.
* I'm not sure what the right the to do with VDSO_NAME_LINUX_4_15 is. It seems
odd that there's nothing newer than 2.6.29 in there.
That probably indicates that any more recent vDSOs added to the Linux
kernel used a version number that reflected when people started developing
them, rather than the version when they actually got into the kernel.
Once it gets into the kernel, the symbol version used for the vDSO by the
kernel becomes part of the kernel/userspace ABI, so fixed even if in some
sense it's the "wrong" version.
If the RISC-V Linux kernel port uses a LINUX_4.15 symbol version for its
vDSO, adding VDSO_NAME_LINUX_4_15 seems right to me.
OK, that makes sense. During the Linux submission process it was suggested we
use 4.15.0, I guess I'm just a bit surprised we're the only ones wo have
something newer than 2.6.29.
* Many copyright cleanups.
Of course, if work on the port goes past 31 December before it's ready to
go in, you'll need to update all copyrights to use <year>-2018 ranges.
Sounds good. DJ wrote a copyright checking script, so it should be easy to
Thanks for all the feedback. I'll go through your messages, and though I
haven't read them yet I assume we'll be submitting a v3.