Porting to RISC-V

Porting to RISC-V

[Dean Michael Ancajas]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

Hi,
  I saw in the Roadmap for 1.2.0 that there will be a porting to RiscV. Is
there someone doing this already? If not, how does one participate and are
there guides on how to port musl to a new architecture?

Dean

[-- Attachment #2: Type: text/html, Size: 273 bytes --]

Re: Porting to RISC-V

[Rich Felker]

On Wed, May 02, 2018 at 03:28:17PM -0400, Dean Michael Ancajas wrote:
> Hi,
>   I saw in the Roadmap for 1.2.0 that there will be a porting to RiscV. Is
> there someone doing this already?

The work is mostly done, but pending details getting it upstream (a
few minor omissions, documentation of authorship, ...).

> If not, how does one participate and are
> there guides on how to port musl to a new architecture?

There's some info on the wiki but it might not be entirely up-to-date.

Rich

Re: Porting to RISC-V

[Dean Michael Ancajas]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Can you send a link of the wiki?

On Wed, May 2, 2018 at 3:37 PM, Rich Felker <dalias@libc.org> wrote:

> On Wed, May 02, 2018 at 03:28:17PM -0400, Dean Michael Ancajas wrote:
> > Hi,
> >   I saw in the Roadmap for 1.2.0 that there will be a porting to RiscV.
> Is
> > there someone doing this already?
>
> The work is mostly done, but pending details getting it upstream (a
> few minor omissions, documentation of authorship, ...).
>
> > If not, how does one participate and are
> > there guides on how to port musl to a new architecture?
>
> There's some info on the wiki but it might not be entirely up-to-date.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1080 bytes --]

Re: Porting to RISC-V

[Rich Felker]

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

> On Wed, May 2, 2018 at 3:37 PM, Rich Felker <dalias@libc.org> wrote:
> 
> > On Wed, May 02, 2018 at 03:28:17PM -0400, Dean Michael Ancajas wrote:
> > > Hi,
> > >   I saw in the Roadmap for 1.2.0 that there will be a porting to RiscV.
> > Is
> > > there someone doing this already?
> >
> > The work is mostly done, but pending details getting it upstream (a
> > few minor omissions, documentation of authorship, ...).
> >
> > > If not, how does one participate and are
> > > there guides on how to port musl to a new architecture?
> >
> > There's some info on the wiki but it might not be entirely up-to-date.
> >
> > Rich
> >

Re: Porting to RISC-V

[Michael Clark]

> On 3/05/2018, at 7:45 AM, Rich Felker <dalias@libc.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@gmail.com>
	Alex Suykov <alex.suykov@gmail.com>
	Michael Clark <michaeljclark@mac.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.

Re: Porting to RISC-V

[Palmer Dabbelt]

On Wed, 02 May 2018 13:37:13 PDT (-0700), michaeljclark@mac.com wrote:
>
>
>> On 3/05/2018, at 7:45 AM, Rich Felker <dalias@libc.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@gmail.com>
> 	Alex Suykov <alex.suykov@gmail.com>
> 	Michael Clark <michaeljclark@mac.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.

I can move it whenever you want.

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

Re: Porting to RISC-V

[Khem Raj]

Hi Palmer

I think move it to riscv github handle and then I can help with
upstreaming in 1.21 timeframe.

Thanks
-Khem
On Wed, May 2, 2018 at 1:51 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 02 May 2018 13:37:13 PDT (-0700), michaeljclark@mac.com wrote:
> >
> >
> >> On 3/05/2018, at 7:45 AM, Rich Felker <dalias@libc.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@gmail.com>
> >       Alex Suykov <alex.suykov@gmail.com>
> >       Michael Clark <michaeljclark@mac.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.
>
> I can move it whenever you want.
>
> > 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.

Re: Porting to RISC-V

[Rich Felker]

On Thu, May 03, 2018 at 08:37:13AM +1200, Michael Clark wrote:
> 
> 
> > On 3/05/2018, at 7:45 AM, Rich Felker <dalias@libc.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@gmail.com>
> 	Alex Suykov <alex.suykov@gmail.com>
> 	Michael Clark <michaeljclark@mac.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?

Rich

Re: Porting to RISC-V

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 6078 bytes --]



> On 23/09/2018, at 12:45 PM, Rich Felker <dalias@libc.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@libc.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@gmail.com>
>>    Alex Suykov <alex.suykov@gmail.com>
>>    Michael Clark <michaeljclark@mac.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.

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

Michael

[1] https://github.com/riscv/riscv-musl

[-- Attachment #2: Type: text/html, Size: 12919 bytes --]

Re: Porting to RISC-V

[Rich Felker]

On Sun, Sep 23, 2018 at 02:40:45PM +1200, Michael Clark wrote:
> 
> 
> > On 23/09/2018, at 12:45 PM, Rich Felker <dalias@libc.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@libc.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@gmail.com>
> >>    Alex Suykov <alex.suykov@gmail.com>
> >>    Michael Clark <michaeljclark@mac.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

Re: Porting to RISC-V

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]


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

Okay. We’ll fix the bugs. Yes, there are now several ways to get RISC-V Linux booting in QEMU.

There are riscv cross tools and riscv qemu binaries in Debian Sid.  I think it is possible to debootstrap riscv64. Indeed the Debian RISC-V builders are running QEMU.

I also have a bootstrap script for a musl riscv gcc 8.1 compiler here:

https://github.com/michaeljclark/musl-riscv-toolchain

You can build the gcc toolchain for comparison:

https://github.com/riscv/riscv-gnu-toolchain

There are links to several Linux images (Fedora, Debian) and build instructions for Linux kernel and bbl on the RISC-V QEMU wiki:

- https://github.com/riscv/riscv-qemu/wiki

Alternatively you can clone SiFive’s freedom-u-sdk and type “make qemu” to get a riscv64 buildroot image booting up in QEMU. This same root image and kernel runs on the HiFive Unleashed Board:

https://github.com/sifive/freedom-u-sdk

Also, Fabrice Belliard has a buildroot port that has recipes for both riscv32 and riscv64:

https://bellard.org/tinyemu/

Normally the kernel is packaged as a payload inside of “bbl”, the Berkeley Boot Loader. However, we now support separate kernel and firmware using the latest bbl, the RISC-V QEMU and “virt” machine in QEMU from the riscv-qemu repository (this feature is not upstream yet) and linux 4.19-rc5 kernel. This is mostly useful if you are recompiling the kernel. We have the -bios, -kernel, -initrd and -append options working:

https://github.com/riscv/riscv-qemu

e.g.

$ qemu-system-riscv64 -nographic -machine virt -bios bbl -kernel vmlinux -initrd initramfs.gz -append rdinit=/bin/busybox

The wiki link above and the freedom-u-sdk have docs and Makefile recipes for attaching VirtIO drives and networking devices.

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

No worries. It’ll be nice to get the port upstream...

Cheers,
Michael

[-- Attachment #2: Type: text/html, Size: 5898 bytes --]