Re: RISC-V glibc port v2

[Palmer Dabbelt <palmer@dabbelt.com>]

On Wed, 20 Dec 2017 08:04:50 PST (-0800), joseph@codesourcery.com 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
>>                                      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.

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
> well-maintained ports).

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 
do :).

> 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 
find everything.

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.