[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311040410.GC1827@brightrain.aerifal.cx>
Date: Wed, 11 Mar 2026 00:04:12 -0400
From: Rich Felker <dalias@...c.org>
To: JianTao Shan <shanjiantao@...ngson.cn>
Cc: musl@...ts.openwall.com, lixing@...ngson.cn, wanghongliang@...ngson.cn,
huajingyun@...ngson.cn
Subject: Re: [PATCH] loongarch64: add fpu and simd context to signal.h
On Mon, Sep 23, 2024 at 02:52:29AM +0000, JianTao Shan wrote:
> The signal stack extension field of loongarch64 is mutable, and the types
> are distinguished according to some magic. The lack of this part of the uapi
> definition will cause some projects such as dotnet to fail to compile on musl.
This has been pending a long time and I want to merge it for the
release I'm trying to roll now. But:
> ---
> arch/loongarch64/bits/signal.h | 50 ++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
> index 5a9ed8c9..1487c0d7 100644
> --- a/arch/loongarch64/bits/signal.h
> +++ b/arch/loongarch64/bits/signal.h
> @@ -18,6 +18,14 @@
> #endif
>
> #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> +/* FP context was used */
> +#define SC_USED_FP (1 << 0)
> +/* Address error was due to memory load */
> +#define SC_ADDRERR_RD (1 << 30)
> +/* Address error was due to memory store */
> +#define SC_ADDRERR_WR (1 << 31)
This is UB. If these are values for the sc_flags member, should they
have unsigned type anyway? So, 1U<<0, 1U<<30, 1U<<31? If there's no
objection I can make that change and commit but I want to make sure
I'm understanding the intent right and that this isn't going to break
some usage.
> +
> +/* FPU context */
> typedef unsigned long greg_t, gregset_t[32];
>
> struct sigcontext {
> @@ -26,6 +34,48 @@ struct sigcontext {
> unsigned sc_flags;
> unsigned long sc_extcontext[] __attribute__((__aligned__(16)));
> };
> +
> +#define CONTEXT_INFO_ALIGN 16
> +struct sctx_info {
> + unsigned magic;
> + unsigned size;
> + unsigned long padding; /* padding to 16 bytes */
> +};
> +
> +#define FPU_CTX_MAGIC 0x46505501
> +#define FPU_CTX_ALIGN 8
> +struct fpu_context {
> + unsigned long regs[32];
> + unsigned long fcc;
> + unsigned fcsr;
> +};
> +
> +/* LSX context */
> +#define LSX_CTX_MAGIC 0x53580001
> +#define LSX_CTX_ALIGN 16
> +struct lsx_context {
> + unsigned long regs[2*32];
> + unsigned long fcc;
> + unsigned fcsr;
> +};
> +
> +/* LASX context */
> +#define LASX_CTX_MAGIC 0x41535801
> +#define LASX_CTX_ALIGN 32
> +struct lasx_context {
> + unsigned long regs[4*32];
> + unsigned long fcc;
> + unsigned fcsr;
> +};
> +
> +/* LBT context */
> +#define LBT_CTX_MAGIC 0x42540001
> +#define LBT_CTX_ALIGN 8
> +struct lbt_context {
> + unsigned long regs[4];
> + unsigned eflags;
> + unsigned ftop;
> +};
> #endif
>
> typedef struct {
> --
> 2.46.1
Otherwise this looks ok except that I'd strip the comments out of
public header when merging.
Rich
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.
