Re: [musl] add loongarch64 port v7.

[王洪亮 <wanghongliang@loongson.cn>]

在 2023/4/18 下午5:38, Szabolcs Nagy 写道:
> * 王洪亮 <wanghongliang@loongson.cn> [2023-04-18 09:28:49 +0800]:
>> +++ b/arch/loongarch64/bits/signal.h
>> @@ -6,14 +6,27 @@
>>   #define SIGSTKSZ    16384
>>   #endif
>>
>> +#if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
>>   typedef unsigned long greg_t, gregset_t[32];
>>
>> -typedef struct sigcontext {
>> +struct sigcontext {
>>       unsigned long sc_pc;
>> -    gregset_t     sc_regs;
>> -    unsigned int  sc_flags;
>> -    unsigned long sc_extcontext[];
>> +    unsigned long sc_regs[32];
>> +    unsigned int sc_flags;
>> +    unsigned long sc_extcontext[] __attribute__((__aligned__(16)));
>> +};
> this looks good. (i don't know if this is really
> needed in signal.h, but other targets have it too)
>
>> +
>> +typedef struct {
>> +    unsigned long __pc;
>> +    unsigned long __gregs[32];
>> +    unsigned int __flags;
>> +    unsigned long __extcontext[] __attribute__((__aligned__(16)));
>>   } mcontext_t;
> i would use the same struct tag as glibc so
>
> typedef struct mcontext_t { ...
>
> (we don't need c++ abi compat with glibc, but
> it's nicer to be consistent)
>
>> +#else
>> +typedef struct {
>> +    unsigned long __space[34];
>> +} mcontext_t;
> i would add the aligned attribute here.
>
> (it's more important to match the kernel layout than to
> avoid c extensions in standard mode: loongarch c compilers
> will all support the aligned attribute in system headers)
I understand there is no need for me to submit modifications,
you help me modify it directly,right?
>> +#endif
>>
>>   struct sigaltstack {
>>       void   *ss_sp;
>> @@ -23,11 +36,10 @@ struct sigaltstack {
>>
>>   typedef struct __ucontext
>>   {
>> -    unsigned long      uc_flags;
>> +    unsigned long      __uc_flags;
>>       struct __ucontext  *uc_link;
>>       stack_t            uc_stack;
>>       sigset_t           uc_sigmask;
>> -    long               __uc_pad;
>>       mcontext_t         uc_mcontext;
>>   } ucontext_t;
> looks good.
>
> (the only issue is if some code uses uc_flags in an
> arch independent way. i don't know if there is any
> use for it on linux. but we can fix that later on
> both glibc and musl side if it comes up.)