This is the mail archive of the
mailing list for the glibc project.
Re: RISC-V glibc port v2
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Palmer Dabbelt <palmer at dabbelt 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 16:04:50 +0000
- Subject: Re: RISC-V glibc port v2
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
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.
> * 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
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).
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.)
> * 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.
> * 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.
Joseph S. Myers