[musl] RISC-V 32bit port in MUSL upstream

[musl] RISC-V 32bit port in MUSL upstream

[Venkata Ramanaiah Nalamothu (QUIC)]

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

Hi,

It looks like the RISC-V 32bit support is not there yet in MUSL upstream and there were past discussions on adding the support (https://www.openwall.com/lists/musl/2020/09/04/2).

Is there any ongoing effort to add RISC-V 32bit port in MUSL? If yes, any idea when that might get completed?

Ram Nalamothu

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

Re: [musl] RISC-V 32bit port in MUSL upstream

[Khem Raj]

On Wed, Sep 27, 2023 at 9:36 AM Venkata Ramanaiah Nalamothu (QUIC)
<quic_vnalamot@quicinc.com> wrote:
>
> Hi,
>
>
>
> It looks like the RISC-V 32bit support is not there yet in MUSL upstream and there were past discussions on adding the support (https://www.openwall.com/lists/musl/2020/09/04/2).
>
>

we maintain these patchset for yocto -
https://github.com/riscv/meta-riscv/tree/master/recipes-core/musl/musl

I also have a github tree.
https://github.com/kraj/musl/commits/kraj/master/

>
> Is there any ongoing effort to add RISC-V 32bit port in MUSL? If yes, any idea when that might get completed?
>
>
>
> Ram Nalamothu

RE: [musl] RISC-V 32bit port in MUSL upstream

[Venkata Ramanaiah Nalamothu (QUIC)]

Thank you very much for sharing the patch set/development branch.

Looking at your github tree commit history, it seems the tree is actively maintained.
May I know what is stopping from pushing these changes into MUSL community version?
Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com> 
Sent: Wednesday, September 27, 2023 11:40 PM
To: musl@lists.openwall.com
Subject: Re: [musl] RISC-V 32bit port in MUSL upstream

On Wed, Sep 27, 2023 at 9:36 AM Venkata Ramanaiah Nalamothu (QUIC) <quic_vnalamot@quicinc.com> wrote:
>
> Hi,
>
>
>
> It looks like the RISC-V 32bit support is not there yet in MUSL upstream and there were past discussions on adding the support (https://www.openwall.com/lists/musl/2020/09/04/2).
>
>

we maintain these patchset for yocto -
https://github.com/riscv/meta-riscv/tree/master/recipes-core/musl/musl

I also have a github tree.
https://github.com/kraj/musl/commits/kraj/master/

>
> Is there any ongoing effort to add RISC-V 32bit port in MUSL? If yes, any idea when that might get completed?
>
>
>
> Ram Nalamothu

Re: [musl] RISC-V 32bit port in MUSL upstream

[Markus Wichmann]

Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> Thank you very much for sharing the patch set/development branch.
>
> Looking at your github tree commit history, it seems the tree is actively maintained.
> May I know what is stopping from pushing these changes into MUSL community version?
> Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?

According to [0], main issue for Rich was that it was not a stable ABI
yet back in 2020. Has that changed yet?

Ciao,
Markus

[0] https://www.openwall.com/lists/musl/2020/03/12/2

RE: [musl] RISC-V 32bit port in MUSL upstream

[Venkata Ramanaiah Nalamothu (QUIC)]

-----Original Message-----
From: Markus Wichmann <nullplan@gmx.net> 
Sent: Friday, September 29, 2023 8:13 PM
To: musl@lists.openwall.com
Subject: Re: [musl] RISC-V 32bit port in MUSL upstream

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> Thank you very much for sharing the patch set/development branch.
>
> Looking at your github tree commit history, it seems the tree is actively maintained.
> May I know what is stopping from pushing these changes into MUSL community version?
> Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?

According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?

Looks like that has changed, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
As per [1],
     * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
        - rv32imac ilp32
        - rv32imafdc ilp32
        - rv32imafdc ilp32d
       The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.

Regards,
Ram Nalamothu

[1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html

Ciao,
Markus

[0] https://www.openwall.com/lists/musl/2020/03/12/2

RE: [musl] RISC-V 32bit port in MUSL upstream

[Venkata Ramanaiah Nalamothu (QUIC)]

Looks like that has changed and the ABI is being considered stable, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
As per [1],
     * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
        - rv32imac ilp32
        - rv32imafdc ilp32
        - rv32imafdc ilp32d
       The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.

Regards,
Ram Nalamothu

[1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html

P.S: Apologies for the repost, the previous response was confusing because of the incorrect formatting.

-----Original Message-----
From: Markus Wichmann <nullplan@gmx.net> 
Sent: Friday, September 29, 2023 8:13 PM
To: musl@lists.openwall.com
Subject: Re: [musl] RISC-V 32bit port in MUSL upstream

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> Thank you very much for sharing the patch set/development branch.
>
> Looking at your github tree commit history, it seems the tree is actively maintained.
> May I know what is stopping from pushing these changes into MUSL community version?
> Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?

According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?

Ciao,
Markus

[0] https://www.openwall.com/lists/musl/2020/03/12/2

RE: [musl] RISC-V 32bit port in MUSL upstream

[Venkata Ramanaiah Nalamothu (QUIC)]

Ping.

-----Original Message-----
From: Venkata Ramanaiah Nalamothu (QUIC) 
Sent: Thursday, October 5, 2023 8:54 AM
To: musl@lists.openwall.com
Subject: RE: [musl] RISC-V 32bit port in MUSL upstream

Looks like that has changed and the ABI is being considered stable, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
As per [1],
     * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
        - rv32imac ilp32
        - rv32imafdc ilp32
        - rv32imafdc ilp32d
       The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.

Regards,
Ram Nalamothu

[1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html

P.S: Apologies for the repost, the previous response was confusing because of the incorrect formatting.

-----Original Message-----
From: Markus Wichmann <nullplan@gmx.net> 
Sent: Friday, September 29, 2023 8:13 PM
To: musl@lists.openwall.com
Subject: Re: [musl] RISC-V 32bit port in MUSL upstream

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> Thank you very much for sharing the patch set/development branch.
>
> Looking at your github tree commit history, it seems the tree is actively maintained.
> May I know what is stopping from pushing these changes into MUSL community version?
> Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?

According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?

Ciao,
Markus

[0] https://www.openwall.com/lists/musl/2020/03/12/2

Re: [musl] RISC-V 32bit port in MUSL upstream

[Rich Felker]

On Wed, Nov 08, 2023 at 03:00:09PM +0000, Venkata Ramanaiah Nalamothu (QUIC) wrote:
> Ping.

I believe this is actually close to ready-to-merge. I just pushed what
I think was the last missing prerequisite patch:

https://git.musl-libc.org/cgit/musl/commit/?id=19563e1850808af216b1b84263bb7e83cccce506

If the riscv32 port builds and works cleanly now with no further
changes to non-arch-specific code, I think it can be upstreamed now.
I'll try to take a look at this in the next couple days.

Rich


> -----Original Message-----
> From: Venkata Ramanaiah Nalamothu (QUIC) 
> Sent: Thursday, October 5, 2023 8:54 AM
> To: musl@lists.openwall.com
> Subject: RE: [musl] RISC-V 32bit port in MUSL upstream
> 
> Looks like that has changed and the ABI is being considered stable, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
> As per [1],
>      * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
>         - rv32imac ilp32
>         - rv32imafdc ilp32
>         - rv32imafdc ilp32d
>        The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.
> 
> Regards,
> Ram Nalamothu
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
> 
> P.S: Apologies for the repost, the previous response was confusing because of the incorrect formatting.
> 
> -----Original Message-----
> From: Markus Wichmann <nullplan@gmx.net> 
> Sent: Friday, September 29, 2023 8:13 PM
> To: musl@lists.openwall.com
> Subject: Re: [musl] RISC-V 32bit port in MUSL upstream
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> 
> Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> > Thank you very much for sharing the patch set/development branch.
> >
> > Looking at your github tree commit history, it seems the tree is actively maintained.
> > May I know what is stopping from pushing these changes into MUSL community version?
> > Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?
> 
> According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?
> 
> Ciao,
> Markus
> 
> [0] https://www.openwall.com/lists/musl/2020/03/12/2

Re: [musl] RISC-V 32bit port in MUSL upstream

[Khem Raj]

Thanks, I will test the patches on top of master this week and let you know

On Sun, Feb 25, 2024 at 6:16 PM Rich Felker <dalias@libc.org> wrote:
>
> On Wed, Nov 08, 2023 at 03:00:09PM +0000, Venkata Ramanaiah Nalamothu (QUIC) wrote:
> > Ping.
>
> I believe this is actually close to ready-to-merge. I just pushed what
> I think was the last missing prerequisite patch:
>
> https://git.musl-libc.org/cgit/musl/commit/?id=19563e1850808af216b1b84263bb7e83cccce506
>
> If the riscv32 port builds and works cleanly now with no further
> changes to non-arch-specific code, I think it can be upstreamed now.
> I'll try to take a look at this in the next couple days.
>
> Rich
>
>
> > -----Original Message-----
> > From: Venkata Ramanaiah Nalamothu (QUIC)
> > Sent: Thursday, October 5, 2023 8:54 AM
> > To: musl@lists.openwall.com
> > Subject: RE: [musl] RISC-V 32bit port in MUSL upstream
> >
> > Looks like that has changed and the ABI is being considered stable, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
> > As per [1],
> >      * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
> >         - rv32imac ilp32
> >         - rv32imafdc ilp32
> >         - rv32imafdc ilp32d
> >        The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.
> >
> > Regards,
> > Ram Nalamothu
> >
> > [1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
> >
> > P.S: Apologies for the repost, the previous response was confusing because of the incorrect formatting.
> >
> > -----Original Message-----
> > From: Markus Wichmann <nullplan@gmx.net>
> > Sent: Friday, September 29, 2023 8:13 PM
> > To: musl@lists.openwall.com
> > Subject: Re: [musl] RISC-V 32bit port in MUSL upstream
> >
> > WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> >
> > Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> > > Thank you very much for sharing the patch set/development branch.
> > >
> > > Looking at your github tree commit history, it seems the tree is actively maintained.
> > > May I know what is stopping from pushing these changes into MUSL community version?
> > > Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?
> >
> > According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?
> >
> > Ciao,
> > Markus
> >
> > [0] https://www.openwall.com/lists/musl/2020/03/12/2

Re: [musl] RISC-V 32bit port in MUSL upstream

[Rich Felker]

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

On Sun, Feb 25, 2024 at 10:17:32PM -0800, Khem Raj wrote:
> Thanks, I will test the patches on top of master this week and let you know

Thanks! I'm looking at the rebased patches and have some comments on
them. For the IPC one (attached here for reference), the time64 stuff
isn't so much for the sake of a legacy time32 ABI (which riscv32
doesn't have), although it does facilitate that too on archs that need
it. It's because the kernel is unable to give natively time64 ipc
structures, and needs translation. In the absence of a legacy ABI to
support, we could do translation that clobbers the same memory the
kernel put the split 32-bit fields in, but it's not aligned so there's
no easy way to do that, and just doing the same thing all other archs
do and having it at the end seems best.

Rich


> On Sun, Feb 25, 2024 at 6:16 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Wed, Nov 08, 2023 at 03:00:09PM +0000, Venkata Ramanaiah Nalamothu (QUIC) wrote:
> > > Ping.
> >
> > I believe this is actually close to ready-to-merge. I just pushed what
> > I think was the last missing prerequisite patch:
> >
> > https://git.musl-libc.org/cgit/musl/commit/?id=19563e1850808af216b1b84263bb7e83cccce506
> >
> > If the riscv32 port builds and works cleanly now with no further
> > changes to non-arch-specific code, I think it can be upstreamed now.
> > I'll try to take a look at this in the next couple days.
> >
> > Rich
> >
> >
> > > -----Original Message-----
> > > From: Venkata Ramanaiah Nalamothu (QUIC)
> > > Sent: Thursday, October 5, 2023 8:54 AM
> > > To: musl@lists.openwall.com
> > > Subject: RE: [musl] RISC-V 32bit port in MUSL upstream
> > >
> > > Looks like that has changed and the ABI is being considered stable, otherwise GLIBC upstream wouldn't have accepted the RISC-V 32bit port, which is available since 2021 in GLIBC upstream.
> > > As per [1],
> > >      * Support for the RISC-V ISA running on Linux has been expanded to run on 32-bit hardware. This is supported for the following ISA and ABI pairs:
> > >         - rv32imac ilp32
> > >         - rv32imafdc ilp32
> > >         - rv32imafdc ilp32d
> > >        The 32-bit RISC-V port requires at least Linux 5.4, GCC 7.1 and binutils 2.28.
> > >
> > > Regards,
> > > Ram Nalamothu
> > >
> > > [1] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
> > >
> > > P.S: Apologies for the repost, the previous response was confusing because of the incorrect formatting.
> > >
> > > -----Original Message-----
> > > From: Markus Wichmann <nullplan@gmx.net>
> > > Sent: Friday, September 29, 2023 8:13 PM
> > > To: musl@lists.openwall.com
> > > Subject: Re: [musl] RISC-V 32bit port in MUSL upstream
> > >
> > > WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> > >
> > > Am Thu, Sep 28, 2023 at 04:39:37AM +0000 schrieb Venkata Ramanaiah Nalamothu (QUIC):
> > > > Thank you very much for sharing the patch set/development branch.
> > > >
> > > > Looking at your github tree commit history, it seems the tree is actively maintained.
> > > > May I know what is stopping from pushing these changes into MUSL community version?
> > > > Were there any technical challenges or someone just need to find time to work with the community to get the changes reviewed/merged?
> > >
> > > According to [0], main issue for Rich was that it was not a stable ABI yet back in 2020. Has that changed yet?
> > >
> > > Ciao,
> > > Markus
> > >
> > > [0] https://www.openwall.com/lists/musl/2020/03/12/2

[-- Attachment #2: 0007-Add-msg-sem-shm-structs-and-other-missing-defines.patch --]
[-- Type: text/plain, Size: 5051 bytes --]

From 26dca4cada48dbcc16bafc998fa7b5f618b12e03 Mon Sep 17 00:00:00 2001
From: Stefan O'Rear <sorear@fastmail.com>
Date: Wed, 9 Sep 2020 11:57:54 -0700
Subject: [PATCH 07/10] Add msg/sem/shm structs and other missing defines

* Define shmid_ds, semid_ds, and semid_ds data structures

* Define ELF_NFPREG, It is used by some userspace applications like gdb

* Zero IPC_64 because the kernel only recognizes one set of IPC commands.

* Copy the IPC_TIME64 bits from arch/arm/bits to trigger the musl code
  for fixing time64 IPC_STAT results.  I'm not super happy with this,
  maybe there should be a new mechanism in musl for fixing IPC_STAT for
  unconditionally-time64 architectures.

* riscv32 _does_ provide both F_GETLK and F_GETLK32; make sure the
  right one in chosen.

Signed-off-by: Stefan O'Rear <sorear@fastmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 arch/riscv32/bits/fcntl.h   |  7 ++++---
 arch/riscv32/bits/ipcstat.h |  1 +
 arch/riscv32/bits/msg.h     | 18 ++++++++++++++++++
 arch/riscv32/bits/sem.h     | 18 ++++++++++++++++++
 arch/riscv32/bits/shm.h     | 31 +++++++++++++++++++++++++++++++
 arch/riscv32/bits/user.h    |  1 +
 arch/riscv32/syscall_arch.h |  2 ++
 7 files changed, 75 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv32/bits/ipcstat.h
 create mode 100644 arch/riscv32/bits/msg.h
 create mode 100644 arch/riscv32/bits/sem.h
 create mode 100644 arch/riscv32/bits/shm.h

diff --git a/arch/riscv32/bits/fcntl.h b/arch/riscv32/bits/fcntl.h
index ecb4d18f..66f84fac 100644
--- a/arch/riscv32/bits/fcntl.h
+++ b/arch/riscv32/bits/fcntl.h
@@ -24,14 +24,15 @@
 #define F_SETFD  2
 #define F_GETFL  3
 #define F_SETFL  4
-#define F_GETLK  5
-#define F_SETLK  6
-#define F_SETLKW 7
 #define F_SETOWN 8
 #define F_GETOWN 9
 #define F_SETSIG 10
 #define F_GETSIG 11
 
+#define F_GETLK  12
+#define F_SETLK  13
+#define F_SETLKW 14
+
 #define F_SETOWN_EX 15
 #define F_GETOWN_EX 16
 
diff --git a/arch/riscv32/bits/ipcstat.h b/arch/riscv32/bits/ipcstat.h
new file mode 100644
index 00000000..4f4fcb0c
--- /dev/null
+++ b/arch/riscv32/bits/ipcstat.h
@@ -0,0 +1 @@
+#define IPC_STAT 0x102
diff --git a/arch/riscv32/bits/msg.h b/arch/riscv32/bits/msg.h
new file mode 100644
index 00000000..7bbbb2bf
--- /dev/null
+++ b/arch/riscv32/bits/msg.h
@@ -0,0 +1,18 @@
+struct msqid_ds {
+	struct ipc_perm msg_perm;
+	unsigned long __msg_stime_lo;
+	unsigned long __msg_stime_hi;
+	unsigned long __msg_rtime_lo;
+	unsigned long __msg_rtime_hi;
+	unsigned long __msg_ctime_lo;
+	unsigned long __msg_ctime_hi;
+	unsigned long msg_cbytes;
+	msgqnum_t msg_qnum;
+	msglen_t msg_qbytes;
+	pid_t msg_lspid;
+	pid_t msg_lrpid;
+	unsigned long __unused[2];
+	time_t msg_stime;
+	time_t msg_rtime;
+	time_t msg_ctime;
+};
diff --git a/arch/riscv32/bits/sem.h b/arch/riscv32/bits/sem.h
new file mode 100644
index 00000000..544e3d2a
--- /dev/null
+++ b/arch/riscv32/bits/sem.h
@@ -0,0 +1,18 @@
+struct semid_ds {
+	struct ipc_perm sem_perm;
+	unsigned long __sem_otime_lo;
+	unsigned long __sem_otime_hi;
+	unsigned long __sem_ctime_lo;
+	unsigned long __sem_ctime_hi;
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+	unsigned short sem_nsems;
+	char __sem_nsems_pad[sizeof(long)-sizeof(short)];
+#else
+	char __sem_nsems_pad[sizeof(long)-sizeof(short)];
+	unsigned short sem_nsems;
+#endif
+	long __unused3;
+	long __unused4;
+	time_t sem_otime;
+	time_t sem_ctime;
+};
diff --git a/arch/riscv32/bits/shm.h b/arch/riscv32/bits/shm.h
new file mode 100644
index 00000000..725fb469
--- /dev/null
+++ b/arch/riscv32/bits/shm.h
@@ -0,0 +1,31 @@
+#define SHMLBA 4096
+
+struct shmid_ds {
+	struct ipc_perm shm_perm;
+	size_t shm_segsz;
+	unsigned long __shm_atime_lo;
+	unsigned long __shm_atime_hi;
+	unsigned long __shm_dtime_lo;
+	unsigned long __shm_dtime_hi;
+	unsigned long __shm_ctime_lo;
+	unsigned long __shm_ctime_hi;
+	pid_t shm_cpid;
+	pid_t shm_lpid;
+	unsigned long shm_nattch;
+	unsigned long __pad1;
+	unsigned long __pad2;
+	unsigned long __pad3;
+	time_t shm_atime;
+	time_t shm_dtime;
+	time_t shm_ctime;
+};
+
+struct shminfo {
+	unsigned long shmmax, shmmin, shmmni, shmseg, shmall, __unused[4];
+};
+
+struct shm_info {
+	int __used_ids;
+	unsigned long shm_tot, shm_rss, shm_swp;
+	unsigned long __swap_attempts, __swap_successes;
+};
diff --git a/arch/riscv32/bits/user.h b/arch/riscv32/bits/user.h
index 2da743ea..0d37de0b 100644
--- a/arch/riscv32/bits/user.h
+++ b/arch/riscv32/bits/user.h
@@ -1,5 +1,6 @@
 #include <signal.h>
 
 #define ELF_NGREG 32
+#define ELF_NFPREG 33
 typedef unsigned long elf_greg_t, elf_gregset_t[ELF_NGREG];
 typedef union __riscv_mc_fp_state elf_fpregset_t;
diff --git a/arch/riscv32/syscall_arch.h b/arch/riscv32/syscall_arch.h
index 9e916c76..c507f15f 100644
--- a/arch/riscv32/syscall_arch.h
+++ b/arch/riscv32/syscall_arch.h
@@ -76,3 +76,5 @@ static inline long __syscall6(long n, long a, long b, long c, long d, long e, lo
 /* We don't have a clock_gettime function.
 #define VDSO_CGT_SYM "__vdso_clock_gettime"
 #define VDSO_CGT_VER "LINUX_2.6" */
+
+#define IPC_64 0
-- 
2.21.0