This is the mail archive of the libc-alpha@sourceware.org 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]

RISC-V glibc port v2


Sorry it's been a while since the v1 patch set, but things have been busy in
RISC-V land.  The biggest development so far has been our Linux port, which has
been accepted into Linus' tree and will be released as part of 4.15.0.  We have
been in binutils since 2.28 and GCC since 7.1.0, but as we've brought up more
complicated software we've found a handful of bugs so it's best to use the
upcoming releases (2.30 and 7.3.0).  Our QEMU port is not yet upstream (we're
preparing it for submission now), and general availiability of the first
commercial, Linux-capable RISC-V chips is scheduled for Q1 2018.  We've had
preliminary ports of Debian, Fedora, and OpenEmbedded to RISC-V, all of which
are currently waiting on glibc so we can declare the ABI stable.

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

While we anticipate we'll want to add an x32-style ABI on rv64i-based systems,
we haven't implemented that anywhere yet.

There's a few things I know that have to be done:

* I need to go through and sanitize the floating-point routines, which I had to
  refactor as a result of the new FP aliasing mechanism.
* 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.
* Should we have padding in __pthread_rwlock_arch_t?  I assume the padding on
  other architectures is there for ABI reasons and shouldn't be necessary for
  new ports, but the ports I usually rely on all have excatly the same padding
  so I'm worried there's another reason for this.
* 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.
* The port was warning-free recently, but I've rebased it a bit so that might
  not be the case any more.
* 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.

I know it's a bit late and that it's a busy time for everyone, but we're really
hoping to get into 2.27 if possible.  We've been maintaing this port out of
tree for years, and I don't think the quality is going to increase
significantly until we get in tree, declare the ABI stable, and users start
really cranking on it.

A (very brief, as it's been 6 months) summary of the changes since the v1 patch
set includes:

* Many copyright cleanups.
* We're using the generic versions of a handful of functions and headers,
  including ieee754.h, mathdef.h mathinline.h, fabs{,f}, and
  fe{disable,enable,get}except.
* Removal of lots of head code, including pthread_lock, atomic_fast.
* A handful of ABI fixes to match our upstreamed Linux port, including
  sigcontext, instruction-cache flushing, and some syscall sanitization.
* We've changed to use libm_alias_{float,double}, like upstream
* Compiler builtins are used for atomics where possible.
* We now mandate the A extension in Linux, support for non-A systems has been
  removed from glibc.

Thanks to everyone who has helped review the patch set!  I believe we've gone
through all the feedback from the first patch set.  Sorry if we've missed
anything, but at this point I think it'd be best to re-submit it -- it's been a
long time since the previous patch set.

Here's the full list of patches v2.  If one gets lost, they'll be availibale on
the riscv-for-submission-v2 branch of http://github.com/riscv/riscv-glibc

[PATCH v2 01/15] RISC-V: Build Infastructure
[PATCH v2 02/15] RISC-V: ABI Implementation
[PATCH v2 03/15] RISC-V: Startup and Dynamic Loading Code
[PATCH v2 04/15] RISC-V: Thread-Local Storage Support
[PATCH v2 05/15] RISC-V: Generic <string.h> Routines
[PATCH v2 06/15] RISC-V: Generic <math.h> and soft-fp Routines
[PATCH v2 07/15] RISC-V: RV32F Support
[PATCH v2 08/15] RISC-V: RV32D, RV64F, and RV64D Support
[PATCH v2 09/15] RISC-V: Atomic and Locking Routines
[PATCH v2 10/15] RISC-V: Linux Syscall Interface
[PATCH v2 11/15] RISC-V: Linux ABI
[PATCH v2 12/15] RISC-V: Linux Startup and Dynamic Loading Code
[PATCH v2 13/15] Add RISC-V dynamic relocations to elf.h
[PATCH v2 14/15] Add linux-4.15 VDSO hash for RISC-V
[PATCH v2 15/15] Add RISC-V to build-many-glibcs.py


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