[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6c181d73-b990-efb7-755d-03ca9bca956e@loongson.cn>
Date: Wed, 11 Mar 2026 14:13:02 +0800
From: lixing <lixing@...ngson.cn>
To: musl@...ts.openwall.com
Cc: shanjiantao@...ngson.cn, Rich Felker <dalias@...c.org>,
huajingyun@...ngson.cn, wanghongliang@...ngson.cn
Subject: Re: [PATCH] loongarch64: add fpu and simd context to signal.h
在 2026/3/11 下午12:04, Rich Felker 写道:
> 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.
yes, it is UB. Thank you.
>> +
>> +/* 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.
thanks.
>
> 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.
