Re: RISC-V glibc port v2

[Joseph Myers <joseph at codesourcery dot 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
>                                      configuration
> * -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 
well-maintained ports).

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
joseph@codesourcery.com