This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RISC-V glibc port v2

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]