[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180923024735.GG17995@brightrain.aerifal.cx>
Date: Sat, 22 Sep 2018 22:47:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Porting to RISC-V
On Sun, Sep 23, 2018 at 02:40:45PM +1200, Michael Clark wrote:
>
>
> > On 23/09/2018, at 12:45 PM, Rich Felker <dalias@...c.org> wrote:
> >
> >> On Thu, May 03, 2018 at 08:37:13AM +1200, Michael Clark wrote:
> >>
> >>
> >>> On 3/05/2018, at 7:45 AM, Rich Felker <dalias@...c.org> wrote:
> >>>
> >>> On Wed, May 02, 2018 at 03:40:04PM -0400, Dean Michael Ancajas wrote:
> >>>> Can you send a link of the wiki?
> >>>
> >>> https://wiki.musl-libc.org/
> >>> https://wiki.musl-libc.org/porting.html
> >>
> >> Here’s a pointer to my fork of Aric Belsito’s tree, including several fixes to get threads and atomics passing libc-tests.
> >>
> >> - https://github.com/michaeljclark/musl-riscv
> >>
> >> This is the list of contributors as far as I know, but I might have to do a deeper inspection of the git history:
> >>
> >> Aric Belsito <lluixhi@...il.com>
> >> Alex Suykov <alex.suykov@...il.com>
> >> Michael Clark <michaeljclark@....com>
> >>
> >> I’ve talked to Palmer Dabbelt about moving the port to the riscv github organisation retaining all of the contributor history. Typically riscv repos are prefixed with riscv- versus suffixed however that is a minor detail. We’ll need to squash the port into some more logical commits as there is quite a bit of churn in the history, however we’ll tag the repo in its current state to keep the contributor history.
> >>
> >> Threads and mutexes are working. I need to sync with latest musl and run libc-tests again and we need to run the tests in RISC-V Linux versus RISC-V QEMU linux-user. Running against linux-kernel will give more accurate results compared to QEMU’s linux-user emulation which may not be 100% accurate. This is easier to do now as there are several glibc based full Linux distros that can be run in QEMU RISC-V and on real hardware with networking and block storage. i.e. we can rsync binaries in over ssh in the QEMU virt machine. Indeed folk have been running self-hosted GCC bootstraps in the Fedora RISC-V port which has toolchain packages. Now there is a Debian port, and iirc there may even be a SUSE port (Palmer?)
> >>
> >> Here is some recent info on QEMU for RISC-V, which might help with the porting effort:
> >>
> >> - https://github.com/riscv/riscv-qemu/wiki
> >> - https://www.sifive.com/blog/2018/04/25/risc-v-qemu-part-2-the-risc-v-qemu-port-is-upstream/
> >>
> >> Here is the last update I sent regarding the RISC-V musl port…
> >>
> >> Issues fixed since picking up GSoC musl-riscv branch:
> >>
> >> • gcc patch to set the musl dynamic linker name (ELF interp) is upstream
> >> • /lib/ld-musl-riscv32.so.1 (-mabi=ilp32d, default, hard float)
> >> • /lib/ld-musl-riscv64.so.1 (-mabi=lp64d, default, hard float)
> >> • /lib/ld-musl-riscv32-sf.so.1 (-mabi=ilp32, soft float)
> >> • /lib/ld-musl-riscv64-sf.so.1 (-mabi=lp64, soft float)
> >> • /lib/ld-musl-riscv32-sp.so.1 (-mabi=ilp32f, single precision)
> >> • /lib/ld-musl-riscv64-sp.so.1 (-mabi=lp64f, single precision)
> >> • fixed failing pthread tests.
> >> • a_cas was deadlocking (updated a_cas in atomic_a.h, fixed missing inline asm constraint)
> >> • defined the minimal set of atomics required by the musl library
> >> • fixed failing sigaltstack tests (update sigaltstack and ucontext in signal.h)
> >> • fixed failing ipc_sem tests (added struct semid_ds in sem.h)
> >> • fixed failing stat tests (defined blksize_t and nlink_t in alltypes.h.in)
> >> • rename sigcontext __regs to gregs so that gcc would compile
> >> • rename _gp to __global_pointer$ in the crt to work with current binutils
> >> • change definition of long double to quadruple precision
> >> • update syscalls.h.in to use asm-generic syscall definitions
> >> • update stat.h to use asm-generic stat definition
> >>
> >> Remaining issues:
> >>
> >> • rebase to current musl-libc
> >> • audit arch/riscv32 and arch/riscv64 headers to make sure they match linux-4.16
> >> • check results of tests that are expected to fail (compare with other architectures)
> >> • ELF thread local variables are not being initialised
> >> • tls_init test is failing
> >>
> >> Note: riscv32 glibc is not yet upstream so the 32-bit ABI is not yet frozen.
> >>
> >> Rich, BTW It seems the TLS offset is directly above the thread pointer (tp).
> >>
> >> $ cat foo.c
> >> __thread int i = 42;
> >>
> >> void foo()
> >> {
> >> i++;
> >> }
> >>
> >> 0000000000010226 <foo>:
> >> 10226: 00022703 lw a4,0(tp) # 0 <i>
> >> 1022a: 2705 addiw a4,a4,1
> >> 1022c: 00e22023 sw a4,0(tp) # 0 <i>
> >> 10230: 8082 ret
> >>
> >> 0000000000010a7a <__set_thread_area>:
> >> 10a7a: 822a mv tp,a0
> >> 10a7c: 4501 li a0,0
> >> 10a7e: 8082 ret
> >>
> >> Michael.
> >
> > Ping.
> >
> > I was hoping to get this merged in 1.1.20, which didn't happen despite
> > it getting delayed for a long time. Is there a chance of it happening
> > soon for 1.1.21?
>
> Yes. I can bump the priority for this.
>
> There hopefully should not be that much more to do on the port to
> get it in shape for upstream. Sorry there have been a lot of things
> going on so this has fallen through the cracks.
>
> There is still the ELF TLS bug, which shouldn’t be hard to fix, but
> we could always mark the port experimental. If it’s in tree; then
> more folk may be interested in fixing bugs. The code also needs some
> review.
I don't want to merge something with known bugs like this, but I'm
happy to participate in fixing it if I know what the issue is and have
a candidate submission that supposedly works modulo the bug to be
fixed. My understanding is that gcc and qemu stuff is upstream now so
it should be simple to me to build and test. Is this correct?
> We moved the port to riscv-musl in the RISC-V GitHub organisation
> [1]. We need to rebase and squash the tree and write a commit
> message containing the contributors list.
>
> The RISC-V rv32 port isn’t in glibc yet and it may be subject to
> change. I need to get a riscv32 Linux kernel running in QEMU so we
> can do testing against glibc... I’ll have to chat to Palmer about
> riscv32, see if there are any ABI issues we need to be aware of. We
> can spend some time this week...
Great!
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
