Messages in this thread | | | Date | Mon, 16 May 2022 11:51:42 +0800 | Subject | Re: [PATCH V10 14/22] LoongArch: Add signal handling support | From | WANG Xuerui <> |
| |
Hi,
On 5/15/22 21:48, Huacai Chen wrote: > diff --git a/arch/loongarch/include/uapi/asm/sigcontext.h b/arch/loongarch/include/uapi/asm/sigcontext.h > new file mode 100644 > index 000000000000..efeb8b3f8236 > --- /dev/null > +++ b/arch/loongarch/include/uapi/asm/sigcontext.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ > +/* > + * Author: Hanlu Li <lihanlu@loongson.cn> > + * Huacai Chen <chenhuacai@loongson.cn> > + * > + * Copyright (C) 2020-2022 Loongson Technology Corporation Limited > + */ > +#ifndef _UAPI_ASM_SIGCONTEXT_H > +#define _UAPI_ASM_SIGCONTEXT_H > + > +#include <linux/types.h> > +#include <linux/posix_types.h> > + > +/* FP context was used */ > +#define USED_FP (1 << 0) > +/* Load/Store access flags for address error */ > +#define ADRERR_RD (1 << 30) > +#define ADRERR_WR (1 << 31) >> I've searched GitHub globally, and my local glibc checkout, for usages >> of these 3 constants, and there seems to be none; please consider >> removing these if doable. We don't want cruft in uapi right from the >> beginning. > They will be used in our glibc, I promise. Okay then. Seems simple enough, and from my quick grepping these appear to be original creations -- not carried over from somewhere else, so it's already highly likely that some of the userland tools need these anyway, just not released yet. >>> + >>> +struct sigcontext { >>> + __u64 sc_pc; >>> + __u64 sc_regs[32]; >>> + __u32 sc_flags; >>> + __u64 sc_extcontext[0] __attribute__((__aligned__(16))); >>> +}; >>> + >>> +#define CONTEXT_INFO_ALIGN 16 >>> +struct _ctxinfo { >>> + __u32 magic; >>> + __u32 size; >>> + __u64 padding; /* padding to 16 bytes */ >>> +}; >>> + >>> +/* FPU context */ >>> +#define FPU_CTX_MAGIC 0x46505501 >>> +#define FPU_CTX_ALIGN 8 >>> +struct fpu_context { >>> + __u64 regs[32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> +}; >> The 3 structs above should already see usage downstream (glibc and other >> low-level friends), so they probably shouldn't be touched by now. At >> least I can't see problems. >>> + >>> +/* LSX context */ >>> +#define LSX_CTX_MAGIC 0x53580001 >>> +#define LSX_CTX_ALIGN 16 >>> +struct lsx_context { >>> + __u64 regs[2*32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> + __u32 vcsr; >>> +}; >>> + >>> +/* LASX context */ >>> +#define LASX_CTX_MAGIC 0x41535801 >>> +#define LASX_CTX_ALIGN 32 >>> +struct lasx_context { >>> + __u64 regs[4*32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> + __u32 vcsr; >>> +}; >> Do we want to freeze the LSX/LASX layout this early, before any detail >> of said extension are published? We'll need to update kernel later >> anyway, so I'd recommend leaving them out for the initial bring-up. > Yes, they are freezed. Okay too, I remember these are the same values as in the old world, so it should be easy to support both worlds at least in this regard. >>> + >>> +#endif /* _UAPI_ASM_SIGCONTEXT_H */ Then I have no problems with this patch then ;-)
| |