arch/loongarch/include/uapi/asm/ptrace.h | 40 ++++++++++++++------------------ 1 file changed, 18 insertions(+), 22 deletions(-)
The kernel UAPI headers already contain fixed-width integer types,
there is no need to rely on libc types. There may not be a libc
available or it may not provide <stdint.h>, like for example on nolibc.
This also aligns the header with the rest of the LoongArch UAPI headers.
Fixes: 803b0fc5c3f2 ("LoongArch: Add process management")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
I'd like to take this through the nolibc tree, as this currently breaks
the upcoming nolibc ptrace support.
---
arch/loongarch/include/uapi/asm/ptrace.h | 40 ++++++++++++++------------------
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/arch/loongarch/include/uapi/asm/ptrace.h b/arch/loongarch/include/uapi/asm/ptrace.h
index aafb3cd9e943..215e0f9e8aa3 100644
--- a/arch/loongarch/include/uapi/asm/ptrace.h
+++ b/arch/loongarch/include/uapi/asm/ptrace.h
@@ -10,10 +10,6 @@
#include <linux/types.h>
-#ifndef __KERNEL__
-#include <stdint.h>
-#endif
-
/*
* For PTRACE_{POKE,PEEK}USR. 0 - 31 are GPRs,
* 32 is syscall's original ARG0, 33 is PC, 34 is BADVADDR.
@@ -41,44 +37,44 @@ struct user_pt_regs {
} __attribute__((aligned(8)));
struct user_fp_state {
- uint64_t fpr[32];
- uint64_t fcc;
- uint32_t fcsr;
+ __u64 fpr[32];
+ __u64 fcc;
+ __u32 fcsr;
};
struct user_lsx_state {
/* 32 registers, 128 bits width per register. */
- uint64_t vregs[32*2];
+ __u64 vregs[32*2];
};
struct user_lasx_state {
/* 32 registers, 256 bits width per register. */
- uint64_t vregs[32*4];
+ __u64 vregs[32*4];
};
struct user_lbt_state {
- uint64_t scr[4];
- uint32_t eflags;
- uint32_t ftop;
+ __u64 scr[4];
+ __u32 eflags;
+ __u32 ftop;
};
struct user_watch_state {
- uint64_t dbg_info;
+ __u64 dbg_info;
struct {
- uint64_t addr;
- uint64_t mask;
- uint32_t ctrl;
- uint32_t pad;
+ __u64 addr;
+ __u64 mask;
+ __u32 ctrl;
+ __u32 pad;
} dbg_regs[8];
};
struct user_watch_state_v2 {
- uint64_t dbg_info;
+ __u64 dbg_info;
struct {
- uint64_t addr;
- uint64_t mask;
- uint32_t ctrl;
- uint32_t pad;
+ __u64 addr;
+ __u64 mask;
+ __u32 ctrl;
+ __u32 pad;
} dbg_regs[14];
};
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251029-loongarch-uapi-ptrace-types-0c5c6756f7e0
Best regards,
--
Thomas Weißschuh <linux@weissschuh.net>
Applied, thanks.
Huacai
On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> The kernel UAPI headers already contain fixed-width integer types,
> there is no need to rely on libc types. There may not be a libc
> available or it may not provide <stdint.h>, like for example on nolibc.
>
> This also aligns the header with the rest of the LoongArch UAPI headers.
>
> Fixes: 803b0fc5c3f2 ("LoongArch: Add process management")
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> I'd like to take this through the nolibc tree, as this currently breaks
> the upcoming nolibc ptrace support.
> ---
> arch/loongarch/include/uapi/asm/ptrace.h | 40 ++++++++++++++------------------
> 1 file changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/arch/loongarch/include/uapi/asm/ptrace.h b/arch/loongarch/include/uapi/asm/ptrace.h
> index aafb3cd9e943..215e0f9e8aa3 100644
> --- a/arch/loongarch/include/uapi/asm/ptrace.h
> +++ b/arch/loongarch/include/uapi/asm/ptrace.h
> @@ -10,10 +10,6 @@
>
> #include <linux/types.h>
>
> -#ifndef __KERNEL__
> -#include <stdint.h>
> -#endif
> -
> /*
> * For PTRACE_{POKE,PEEK}USR. 0 - 31 are GPRs,
> * 32 is syscall's original ARG0, 33 is PC, 34 is BADVADDR.
> @@ -41,44 +37,44 @@ struct user_pt_regs {
> } __attribute__((aligned(8)));
>
> struct user_fp_state {
> - uint64_t fpr[32];
> - uint64_t fcc;
> - uint32_t fcsr;
> + __u64 fpr[32];
> + __u64 fcc;
> + __u32 fcsr;
> };
>
> struct user_lsx_state {
> /* 32 registers, 128 bits width per register. */
> - uint64_t vregs[32*2];
> + __u64 vregs[32*2];
> };
>
> struct user_lasx_state {
> /* 32 registers, 256 bits width per register. */
> - uint64_t vregs[32*4];
> + __u64 vregs[32*4];
> };
>
> struct user_lbt_state {
> - uint64_t scr[4];
> - uint32_t eflags;
> - uint32_t ftop;
> + __u64 scr[4];
> + __u32 eflags;
> + __u32 ftop;
> };
>
> struct user_watch_state {
> - uint64_t dbg_info;
> + __u64 dbg_info;
> struct {
> - uint64_t addr;
> - uint64_t mask;
> - uint32_t ctrl;
> - uint32_t pad;
> + __u64 addr;
> + __u64 mask;
> + __u32 ctrl;
> + __u32 pad;
> } dbg_regs[8];
> };
>
> struct user_watch_state_v2 {
> - uint64_t dbg_info;
> + __u64 dbg_info;
> struct {
> - uint64_t addr;
> - uint64_t mask;
> - uint32_t ctrl;
> - uint32_t pad;
> + __u64 addr;
> + __u64 mask;
> + __u32 ctrl;
> + __u32 pad;
> } dbg_regs[14];
> };
>
>
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20251029-loongarch-uapi-ptrace-types-0c5c6756f7e0
>
> Best regards,
> --
> Thomas Weißschuh <linux@weissschuh.net>
>
>
Hi, Thomas,
On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> The kernel UAPI headers already contain fixed-width integer types,
> there is no need to rely on libc types. There may not be a libc
> available or it may not provide <stdint.h>, like for example on nolibc.
>
> This also aligns the header with the rest of the LoongArch UAPI headers.
Thank you for your patch, but could you please tell me some history
and user guide about the three styles: u64, __u64 and unint64_t?
Huacai
>
> Fixes: 803b0fc5c3f2 ("LoongArch: Add process management")
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> I'd like to take this through the nolibc tree, as this currently breaks
> the upcoming nolibc ptrace support.
> ---
> arch/loongarch/include/uapi/asm/ptrace.h | 40 ++++++++++++++------------------
> 1 file changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/arch/loongarch/include/uapi/asm/ptrace.h b/arch/loongarch/include/uapi/asm/ptrace.h
> index aafb3cd9e943..215e0f9e8aa3 100644
> --- a/arch/loongarch/include/uapi/asm/ptrace.h
> +++ b/arch/loongarch/include/uapi/asm/ptrace.h
> @@ -10,10 +10,6 @@
>
> #include <linux/types.h>
>
> -#ifndef __KERNEL__
> -#include <stdint.h>
> -#endif
> -
> /*
> * For PTRACE_{POKE,PEEK}USR. 0 - 31 are GPRs,
> * 32 is syscall's original ARG0, 33 is PC, 34 is BADVADDR.
> @@ -41,44 +37,44 @@ struct user_pt_regs {
> } __attribute__((aligned(8)));
>
> struct user_fp_state {
> - uint64_t fpr[32];
> - uint64_t fcc;
> - uint32_t fcsr;
> + __u64 fpr[32];
> + __u64 fcc;
> + __u32 fcsr;
> };
>
> struct user_lsx_state {
> /* 32 registers, 128 bits width per register. */
> - uint64_t vregs[32*2];
> + __u64 vregs[32*2];
> };
>
> struct user_lasx_state {
> /* 32 registers, 256 bits width per register. */
> - uint64_t vregs[32*4];
> + __u64 vregs[32*4];
> };
>
> struct user_lbt_state {
> - uint64_t scr[4];
> - uint32_t eflags;
> - uint32_t ftop;
> + __u64 scr[4];
> + __u32 eflags;
> + __u32 ftop;
> };
>
> struct user_watch_state {
> - uint64_t dbg_info;
> + __u64 dbg_info;
> struct {
> - uint64_t addr;
> - uint64_t mask;
> - uint32_t ctrl;
> - uint32_t pad;
> + __u64 addr;
> + __u64 mask;
> + __u32 ctrl;
> + __u32 pad;
> } dbg_regs[8];
> };
>
> struct user_watch_state_v2 {
> - uint64_t dbg_info;
> + __u64 dbg_info;
> struct {
> - uint64_t addr;
> - uint64_t mask;
> - uint32_t ctrl;
> - uint32_t pad;
> + __u64 addr;
> + __u64 mask;
> + __u32 ctrl;
> + __u32 pad;
> } dbg_regs[14];
> };
>
>
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20251029-loongarch-uapi-ptrace-types-0c5c6756f7e0
>
> Best regards,
> --
> Thomas Weißschuh <linux@weissschuh.net>
>
>
Hi Huacai,
On 2025-11-03 17:12:58+0800, Huacai Chen wrote:
> On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
> >
> > The kernel UAPI headers already contain fixed-width integer types,
> > there is no need to rely on libc types. There may not be a libc
> > available or it may not provide <stdint.h>, like for example on nolibc.
> >
> > This also aligns the header with the rest of the LoongArch UAPI headers.
> Thank you for your patch, but could you please tell me some history
> and user guide about the three styles: u64, __u64 and unint64_t?
uint64_t -> userspace type, should not be used within the kernel
can technically be used in UAPI it will be somewhat
nonstandard and introduce a dependency on libc with no
upsides.
u64 -> kernel-internal type, used for regular kernel code
defined in include/linux/types.h
__u64 -> UAPI type usable from both kernel and userspace code
defined in include/uapi/linux/types.
As a note: When applying the patch I want to clarify the commit message
a bit, as nolibc indeed has a stdint.h header. The real breakage comes
from a validation step we perform which does not add the libc include
directory to the include path.
Thomas
On Mon, Nov 3, 2025 at 5:27 PM Thomas Weißschuh <linux@weissschuh.net> wrote: > > Hi Huacai, > > On 2025-11-03 17:12:58+0800, Huacai Chen wrote: > > On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@weissschuh.net> wrote: > > > > > > The kernel UAPI headers already contain fixed-width integer types, > > > there is no need to rely on libc types. There may not be a libc > > > available or it may not provide <stdint.h>, like for example on nolibc. > > > > > > This also aligns the header with the rest of the LoongArch UAPI headers. > > > Thank you for your patch, but could you please tell me some history > > and user guide about the three styles: u64, __u64 and unint64_t? > > uint64_t -> userspace type, should not be used within the kernel > can technically be used in UAPI it will be somewhat > nonstandard and introduce a dependency on libc with no > upsides. But a simple grep shows there are many uses of uint64_t in the kernel code, are they all wrong? Huacai > > u64 -> kernel-internal type, used for regular kernel code > defined in include/linux/types.h > > __u64 -> UAPI type usable from both kernel and userspace code > defined in include/uapi/linux/types. > > As a note: When applying the patch I want to clarify the commit message > a bit, as nolibc indeed has a stdint.h header. The real breakage comes > from a validation step we perform which does not add the libc include > directory to the include path. > > > Thomas
On 2025-11-03 17:38:49+0800, Huacai Chen wrote: > On Mon, Nov 3, 2025 at 5:27 PM Thomas Weißschuh <linux@weissschuh.net> wrote: > > On 2025-11-03 17:12:58+0800, Huacai Chen wrote: > > > On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@weissschuh.net> wrote: > > > > > > > > The kernel UAPI headers already contain fixed-width integer types, > > > > there is no need to rely on libc types. There may not be a libc > > > > available or it may not provide <stdint.h>, like for example on nolibc. > > > > > > > > This also aligns the header with the rest of the LoongArch UAPI headers. > > > > > Thank you for your patch, but could you please tell me some history > > > and user guide about the three styles: u64, __u64 and unint64_t? > > > > uint64_t -> userspace type, should not be used within the kernel > > can technically be used in UAPI it will be somewhat > > nonstandard and introduce a dependency on libc with no > > upsides. > But a simple grep shows there are many uses of uint64_t in the kernel > code, are they all wrong? Yes, they are wrong. See also the explanation from Arnd. > > u64 -> kernel-internal type, used for regular kernel code > > defined in include/linux/types.h > > > > __u64 -> UAPI type usable from both kernel and userspace code > > defined in include/uapi/linux/types. > > > > As a note: When applying the patch I want to clarify the commit message > > a bit, as nolibc indeed has a stdint.h header. The real breakage comes > > from a validation step we perform which does not add the libc include > > directory to the include path.
© 2016 - 2026 Red Hat, Inc.