Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Sep 2018 14:40:45 +1200
From: Michael Clark <>
Subject: Re: Porting to RISC-V

> On 23/09/2018, at 12:45 PM, Rich Felker <> wrote:
>> On Thu, May 03, 2018 at 08:37:13AM +1200, Michael Clark wrote:
>>> On 3/05/2018, at 7:45 AM, Rich Felker <> wrote:
>>> On Wed, May 02, 2018 at 03:40:04PM -0400, Dean Michael Ancajas wrote:
>>>> Can you send a link of the wiki?
>> Here’s a pointer to my fork of Aric Belsito’s tree, including several fixes to get threads and atomics passing libc-tests.
>>    -
>> 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 <>
>>    Alex Suykov <>
>>    Michael Clark <>
>> 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:
>>    -
>>    -
>> 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/ (-mabi=ilp32d, default, hard float)
>>        • /lib/ (-mabi=lp64d, default, hard float)
>>        • /lib/ (-mabi=ilp32, soft float)
>>        • /lib/ (-mabi=lp64, soft float)
>>        • /lib/ (-mabi=ilp32f, single precision)
>>        • /lib/ (-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
>>    • 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 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.

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


Content of type "text/html" skipped

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.